Repeatable crash with CVS version of cygwin1 DLL

Cliff Geschke cliff_pa@geschkefamily.com
Fri Feb 20 16:34:00 GMT 2004


What!!

Are you trying to tell me that I can only call setjmp from the main program?

I don't know what man page you are reading, but you are misunderstanding what it
says.  Setjmp/longjmp does not trash (or is not supposed to trash) the call
stack.  It can trash the auto variables in the local routine ("stack context")
that contains the setjmp call, but that is not an issue here.

The problem is that the current setjmp/longjmp implementation is not
saving/restoring all the context required by the new sig* routines.

Now you are making me wonder if RTEMS should be using sigsetjmp/siglongjmp.  I
am not trying to become an RTEMS developer.

I'll let you know what I find out, but I still think this crash is a cygwin bug.

Thanks,

Cliff Geschke

--------------------------------------------------------------------------------

On Thu, Feb 19, 2004 at 07:10:02PM -0500, Christopher Faylor wrote:
>On Thu, Feb 19, 2004 at 05:58:59PM -0600, Cliff Geschke wrote:
>>>From: Christopher Faylor [mailto:cgf-no-personal-reply-please@cygwin.com] 
>>>Sent: Thursday, February 19, 2004 12:05 AM
>>>Subject: Re: Repeatable crash with CVS version of cygwin1 DLL
>>>
>>>On Wed, Feb 18, 2004 at 11:03:21PM -0600, Cliff Geschke wrote:
>>>>I have tried the latest update from CVS.  Still crashes, but stackptr 
>>>>does not go out-of-bounds.  At some point, _sigbe tries to ret with the 
>>>>top of stack ($esp) value set to 0.
>>>>
>>>>Some additional data points:
>>>>
>>>>1.  I moved the test .exe file to a Win2000 box running an old 
>>>>cygwin1.dll (file version 1005.5.0.0, product version 1.5.5-cr-0x9b).
>>>>No crash.  The test seems to run fine.
>>>
>>>Sorry.  The fact that this worked in 1.5.5 is uninteresting.
>>
>>Actually it _is_ interesting because it means that the crash is not due to
some
>>bogus use of longjmp/setjmp in my test program.
>
>It doesn't necessarily mean that.  Just because something worked in
>1.5.5 doesn't mean that your app uses setjmp correctly.
>
>In fact, on rereading the code snippet that you posted, it actually is
>using setjmp incorrectly.  It calls setjmp in a function and then
>(potentially) returns.  When it doesn't return it jumps to another
>thread context which almost has to invalidate the setjmp context by
>default.  That invalidates the jmp_buf argument to setjmp.  I don't know
>if this is really an actual code sample but, if it is, it doesn't seem
>to be compliant with this sentence from the setjmp man page:
>
>"The stack context will be invalidated  if  the  function  which  called
>setjmp() returns."
>
>>Okay, you asked for it...
>>uudecode, gunzip, (chmod maybe) then ./ticker.exe
>>It should type a message every 5 seconds for 30 seconds.
>>But it crashes after the 2nd message.
>
>Ok.  I'll look at it.

As it turns out, your test program does exactly what I mentioned above.
It uses longjmp to jump to a position in the stack that is essentially
out-of-date.  The signal stack has since been cleared so it ends up
jumping to location 0.

I'm not sure how this would work on linux or any other OS.  Is there
code that does some stack magic or something?

cgf




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list