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




reply via email to

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