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:
[EMAIL PROTECTED] 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
