[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: next snapshot in preparation for m4 1.4.12
From: |
Tom G. Christensen |
Subject: |
Re: next snapshot in preparation for m4 1.4.12 |
Date: |
Mon, 8 Sep 2008 19:49:30 +0200 |
User-agent: |
Mutt/1.4.2.2i |
On Sun, Sep 07, 2008 at 08:29:44AM -0600, Eric Blake wrote:
> According to Tom G. Christensen on 9/7/2008 4:47 AM:
> > 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.
>
Curiously I can move char mystack into the global scope and it still
works but only when built with gcc (and then I can't debug since that
requires using gas which I can't with my current gcc).
> 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.
>
I think I sort of understand however I'm out of my league here.
> > 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.
>
I used a snippet from configure but same deal.
> 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.
>
I don't have a clue where to go from here so I'm done.
-tgc