bug-gnulib
[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: Sun, 07 Sep 2008 08:29:44 -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

[re-adding bug-gnulib, we are still trying to figure out why
test-c-stack.c fails on Irix 5.3 with libsigsegv 2.6, even though m4's
stack overflow test passed]

According to Tom G. Christensen on 9/7/2008 4:47 AM:
[c-stack.m4 uses a simpler recurse() than libsigsegv, perhaps the compiler
is over-optimizing it]
> <snip recurse functions>
>> I wonder if switching to libsigsegv's version will solve it.
>>
> After a bit of fidling I can say that it won't.
> I replaced the recurse function in the m4 conftest with the ones from
> libsigsegv and it still dumps core.

Oh well.  I'll probably check in a patch to switch c-stack.m4 and
test-c-stack.c to use libsigsegv's more elaborate recurse() anyways.

> 
> I've spent some time staring at m4s c-stack conftest program and a
> similar one from libsigsegv and after some trial and error I've isolated
> a change which will cause the m4 c-stack conftest to run succesfully.
> 
> --- conftest-1.c      2008-09-02 16:42:49.000000000 +0200
> +++ conftest-3.c      2008-09-07 12:12:32.630000000 +0200
> @@ -74,13 +74,14 @@
>        static int
>        c_stack_action ()
>        {
> +        char mystack[SIGSTKSZ];
>          stack_t st;
>          struct sigaction act;
>          int r;
>   
>          st.ss_flags = 0;
> -        st.ss_sp = alternate_signal_stack.buffer;
> -        st.ss_size = sizeof alternate_signal_stack.buffer;
> +        st.ss_sp = mystack;
> +        st.ss_size = sizeof (mystack);
>          r = sigaltstack (&st, 0);
>          if (r != 0)
>            return r;
> 
> $ cc -woff 728 -o conftest-3 -g conftest-3.c
> $ ./conftest-3
> $ echo $?
> 0
> $
> 
> Apparently using a union to define the alternate stack like c-stack does
> has some issues.

That's not necessarily because it was a union.  Rather, it looks like the
difference is whether the alternate stack lives in on the existing stack
instead of in .bss.

That said, your code is conceptually very dangerous - it is
stack-allocating an alternate stack, then returning from the function that
did the stack allocation; thus, the alternate stack is no longer
allocated, and stack overflow will overwrite the existing stack (ie. you
can't longjmp out of your overflow handler, because you've destroyed what
you would be longjmp'ing to).  On the other hand, c-stack does not
currently provide a way for applications to longjmp out of stack overflow;
the contract currently states that the c-stack handler must terminate.

> Looking briefly at libsigsegv it seems to never use the union style but
> instead always uses a definition similar to the above.

Yes, libsigsegv's stackoverflow1.c stack-allocates its alternate stack.
But it does so in main(), so that the alternate stack is never
unallocated, and stack overflow is not clobbering the original stack.  But
m4's stack overflow used c-stack, which used the union living in .bss
storage, and it worked just fine.  In other words, while your changes made
the c-stack test pass, you have not identified the real reason why m4's
stack overflow test is passing, but test-c-stack is failing, on Irix 5.3.

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

iEYEARECAAYFAkjD5VgACgkQ84KuGfSFAYCloQCfcSQ9GAbbGJS64iYDHhT7RHBx
XdUAoJJNc7LjQu+cDkc3exzZWPAHvkR4
=wHpc
-----END PGP SIGNATURE-----




reply via email to

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