Hoi, Test again... # echo 'define(a,a(a))a' | u:/m4-1.4.11.34-9ecd/src/m4 \ > -L0 -dtx --debugfile=trace # tail trace m4trace: -3688- id 7376: a m4trace: -3689- id 7378: a m4trace: -3690- id 7380: a m4trace: -3691- id 7382: a m4trace: -3692- id 7384: a m4trace: -3693- id 7386: a m4trace: -3694- id 7388: a m4trace: -3695- id 7390: a m4trace: -3696- id 7392: a m4trace: -3697- id 7394: a
Later i rebuild with the --without-libsigsegv-prefix And for logging i use 2>&1 |tee log.make Eric Blake wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Elbert Pol on 8/11/2008 1:51 PM: | Thanks for your updated reports. It looks like libsigsegv won't help you | unless you find someone willing to port it to your platform. Actually, according to your logs, libsigsegv did make a difference - with libsigsegv installed, the c-stack module recognized that no one yet knows how to gracefully detect stack overflow on your platform, so the stack overflow tests were properly skipped rather than causing failures. | |> # m4 --help | grep limit |> -L, --nesting-limit=NUMBER change artificial nesting limit Oops - that was the installed m4. I wanted to see the --help of the just-built m4,... |> # echo 'define(a,a(a))a' | u:/m4-1.4.11.34-9ecd/src/m4 |> m4:stdin:1: recursion limit of 1024 exceeded, use -L<N> to change it ...but this ended up confirming that the just-built m4, when libsigsegv is present, artificially caps recursion since stack overflow is undetectable. However, I'm still interested in seeing what this does when libsigsegv is not present (you can use './configure --without-libsigsegv-prefix' to rebuild m4 without it, rather than having to uninstall the library). Not everyone will have libsigsegv, so it would be nice to fix c-stack.m4 to detect whatever it is about your platform that makes stack overflows apparently undetectable. I did notice from your config.log that your system has sigaltstack and sa_sigaction (unlike mingw or cygwin); most platforms with alternate stack support can usefully trap stack overflow, even if they can't distinguish it from other segv. But in your case, it appears that libsigsegv was correct that installing a SIGSEGV handler on the alternate stack does not work when it comes to stack overflow. | | $ echo 'define(a,a(a))a' | u:/m4-1.4.11.34-9ecd/src/m4 \ | ~ -L0 -dtx --debugfile=trace | $ tail trace |> Dunno if i do the right way but........ |> # echo 'define(a,a(a))a' | u:/m4-1.4.11.34-9ecd/src/m4 \ |> > ~ -L0 -dtx --debugfile=trace Oops, gpg software strikes again (maybe I should quit using inline signatures, although I've also had bad luck with multipart signatures being munged). You interpreted the "~" inserted by my signature process as a command-line argument, so m4 tried to process the contents of your home directory as an m4 input file... |> m4: Warning: cannot protect input file across forks: Operation not |> supported on |> socket |> .bash_historyþø¬O.dssaver/pÍQ.mplayer with rather disastrous consequences. Most modern platforms fail with EISDIR on attempts to read directories, but older systems still allow it. ~ For a contrast, on Linux: $ m4 / m4:/:1: read error Hmm - I wonder if it would be worth making gnulib provide wrappers that guarantee failure on attempts to read(2) directories, to match the behavior of modern implementations? On the other hand, intercepting all the various forms of read calls is rather hard; something more like git's recent patch to override fopen(3) to guarantee failure when opening a directory would be easier to maintain: http://repo.or.cz/w/git.git?a=commitdiff;h=8ce1f243 even though technically, it looks like POSIX requires fopen("/","r") to succeed, only permitting the failure to occur on subsequent attempts to then read from that FILE. At any rate, if you want to repeat the test, omit the ~. But you answered my underlying question anyways - I was worried whether stack overflow might have been occurring before the arbitrary limit of 1024, but the fact that you got a failure message suggesting using the use of -L proves that your default stack size handles 1024 just fine. I'd also be interested in knowing why you had a different set of test failures when libsigsegv was in use than without it: checks/178.sysval reported 512 instead of 65280 after passing "exit 2" to system(3) and popen(3); both wrong values, but not consistent checks/180.mkstemp passed in your first log, and failed from a misparsed child process command line in your second tests/test-strtod passed in your first log, and died from SIGFPE in your second It's really annoying that your platform isn't printing the line number of the gnulib test failures, even though we do an fflush prior to calling abort (or maybe your logs only captured stdout, and omitted stderr?) - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----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 iEYEARECAAYFAkihB+gACgkQ84KuGfSFAYBqmACePQK7W8JgpcxgCC4gHtZ3a6Mf CasAmwTtto9wWfJJiOU5V+w+dnW6rmwQ =VImZ -----END PGP SIGNATURE-----
