[Top][All Lists]

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

Re: os/2 c-stack [was: snapshot in preparation for m4 1.4.12]

From: Elbert Pol
Subject: Re: os/2 c-stack [was: snapshot in preparation for m4 1.4.12]
Date: Wed, 13 Aug 2008 20:17:36 +0200
User-agent: Thunderbird 3.0a1 (OS/2/2008051420)

Hello Eric,

I build now with --without-libsigsegv-prefix

I attach resulst

Eric Blake wrote:
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-
|> 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- \
| ~ -L0 -dtx --debugfile=trace
| $ tail trace
|> Dunno if i do the right way but........
|> # echo 'define(a,a(a))a' | u:/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:
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

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 address@hidden
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


Attachment: check.out.lzma
Description: Binary data

Attachment: config.log.lzma
Description: Binary data

Attachment: make.out.lzma
Description: Binary data

reply via email to

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