This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Repeatable crash with CVS version of cygwin1 DLL


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]