bug-m4
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: next snapshot in preparation for m4 1.4.12


From: Eric Blake
Subject: Re: next snapshot in preparation for m4 1.4.12
Date: Thu, 28 Aug 2008 07:08:23 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?  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.
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).

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).  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.

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.

> test-vasprintf-posix.c:1338: assertion failed
> /bin/ksh[10]: 18410 Abort(coredump)
> FAIL: test-vasprintf-posix

> test-signbit.c:149: assertion failed
> /bin/sh[10]: 34433260 Abort(coredump)
> FAIL: test-signbit

These are separate issues; let's work on the c-stack failure first.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki2o0cACgkQ84KuGfSFAYC7DACffW3O5BkVlPq9W98KMwchzoBE
RmIAoK9i2X5/Xg+8+TQxN8KwgKkTdlAI
=IiMd
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]