Re: next snapshot in preparation for m4 1.4.12

[Tom G. Christensen]

On Thu, Aug 28, 2008 at 07:08:23AM -0600, Eric Blake wrote:
> According to Tom G. Christensen on 8/26/2008 2:28 PM:
> >>
> > Full buildlogs for Irix 5.3 & 6.5 was uploaded to http://jupiterrise.com/tmp
> > 
> > The c-stack test stil fails on both platforms even with the new
> > libsigsegv.
> > 
> > Irix 5.3:
> > Segmentation fault - core dumped
> > FAIL: test-c-stack.sh
> > FAIL: test-c-stack2.sh
> 
> Your logs show that libsigsegv-2.6 passed its self-test on Irix 5.3.
> Looking at the m4 build log, you are definitely linking with libsigsegv:
> 
> | checking for libsigsegv... yes
> | checking how to link with libsigsegv... /usr/tgcware/lib/libsigsegv.so
> - -Wl,-rpath -Wl,/usr/tgcware/lib
> 
> The configure test for c-stack gave up, even without trying sa_sigaction:
> 
> | checking for working C stack overflow detection... no
> 
> Can you include the config.log snippet for that portion of the configure
> run, so we can see if it was a compile or run failure? 
>
configure:6499: checking for working C stack overflow detection
configure:6591: cc -o conftest -g -I/usr/tgcware/include -L/usr/tgcware/lib 
-Wl,-rpath,/usr/tgcware/lib conftest.c  >&5
cfe: Warning 728: conftest.c, line 62: Long double not supported; double 
assumed.
           long double ld;
        ---^
configure:6595: $? = 0
configure:6601: ./conftest
./configure[6603]: 7578 Memory fault(coredump)
configure:6605: $? = 139
configure: program exited with status 139

>If it was a run
> failure, you might want to extract that program from config.log, recompile
> it, and step through it with the debugger to report where it is failing.
>
Running dbx with the corefile gives this backtrace:
address@hidden src]$ dbx conftest
dbx version 3.19 Nov  3 1994 19:59:46
Core from signal SIGSEGV: Segmentation violation
(dbx) t
>  0 recurse(p = (nil)) ["/usr/people/tgc/buildpkg/m4/src/conftest.c":96, 
> 0x400bec]
   1 recurse(p = 0x7ff0038c = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   2 recurse(p = 0x7ff005a4 = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   3 recurse(p = 0x7ff007bc = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   4 recurse(p = 0x7ff009d4 = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   5 recurse(p = 0x7ff00bec = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   6 recurse(p = 0x7ff00e04 = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   7 recurse(p = 0x7ff0101c = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   ....
   ....
   1016 recurse(p = 0x7ff850b4 = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   1017 recurse(p = 0x7ff852cc = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   1018 recurse(p = 0x7ff854e4 = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   1019 recurse(p = 0x7ff856fc = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   1020 recurse(p = 0x7ff85914 = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   1021 recurse(p = 0x7ff85b2c = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   1022 recurse(p = 0x7ff85d44 = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
   1023 recurse(p = 0x7ff85f5c = "\001") 
["/usr/people/tgc/buildpkg/m4/src/conftest.c":99, 0x400c10]
(dbx)

I cut out 8->1015, they're exactly the same, just the value for p changes.

I'm lost as to how I can step through this to see where it fails.

> At any rate, I'm also interested in seeing how c-stack behaves if you
> don't link with libsigsegv (in the earlier snapshot, your build showed
> that c-stack still attempted stack overflow detection and crashed, causing
> ./stackovf.test to FAil; my hope is that I've fixed things so that in this
> snapshot so that c-stack returns ENOTSUPP, letting ./stackovf.test Skip).
> 
Yes, it seems to do the right thing now.

c_stack_action: Invalid argument
SKIP: test-c-stack.sh
c_stack_action: Invalid argument
SKIP: test-c-stack2.sh

Full log uploaded to the usual place.

> Your log also shows that with libsigsegv, ./stackovf.test passed - so m4
> was able to detect stack overflow, even though test-c-stack was not.  That
> seems to point to a lingering bug in the tests/test-c-stack.c file.  To
> help track it: run 'make clean', then, with libsigsegv in use, run
>  'env CFLAGS="-DDEBUG=1 -g" make -e'
> (forcing lib/c-stack.c to be compiled with debugging).  From there, 'cd
> tests && make check' (DEBUG impacts M4's build as well, which will
> probably make m4 tests fail, but we are only interested in debugging why
> tests/test-c-stack is failing).
>
The m4 build now fails but atleast the gnulib tests build and run.

source='input.c' object='input.o' libtool=no \
        DEPDIR=.deps depmode=sgi /bin/ksh ../build-aux/depcomp \
        cc    -I../lib -I../lib -I/usr/tgcware/include  -DDEBUG=1 -g -c input.c
cfe: Error: input.c, line 1120: The number of arguments doesn't agree with the 
number in the declaration.
   while ((t = next_token (&td)) != TOKEN_EOF)
 -------------------------^
make[2]: *** [input.o] Error 1
make[2]: Leaving directory 
`/usr/people/tgc/buildpkg/m4/src/m4-1.4.11.42-864d/src'

> Regardless of those test results, you
> should now be able to run the just-built debugging version of
> 'tests/test-c-stack'.  Run without arguments to trigger stack overflow,
> and with any arguments (contents don't matter, just that argc>1) to
> trigger an unrelated segv; it would be nice to step through both of those
> cases in the debugger and see why they are dying abruptly rather than
> detecting the problem and printing a nice status.
> 
I tried to do this but I after poking at it for awhile I realised I
have no idea what I should be looking for, what I should be stepping
through or even how to do it right :(

What I found if anything is that running test-c-stack with no arguments
results in the same backtrace as above.
Running it with arguments results in:
Executable /usr/people/tgc/buildpkg/m4/src/m4-1.4.11.42-864d/tests/test-c-stack
(dbx) run blah
Process 18820 (test-c-stack) started
Process 18820 (test-c-stack) stopped on signal SIGSEGV: Segmentation violation 
(handler sigsegv_handler) [main:73 +0x18,0x400e78]
  73  ++*argv[argc]; /* Intentionally dereference NULL.  */
(dbx) t
>  0 main(argc = 2, argv = 0x7ffbff04) 
> ["/usr/people/tgc/buildpkg/m4/src/m4-1.4.11.42-864d/tests/test-c-stack.c":73, 
> 0x400e78]
   1 __start() ["crt1text.s":133, 0x400d1c]
(dbx) 

> Are you using GNU make?  Which debugger?  If it's gdb, then I can offer
> further tips on what things looked like in my gdb session.
> 
Yes, GNU make 3.81.
I've been using dbx but I have a copy of gdb 4.17 aswell.
Not sure how that would compare to gdb 6.x though.

-tgc