Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 19 Feb 2004 21:43:25 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Repeatable crash with CVS version of cygwin1 DLL Message-ID: <20040220024325.GA28808@redhat.com> Mail-Followup-To: cygwin AT cygwin DOT com References: <20040219060514 DOT GA11752 AT redhat DOT com> <200402192359 DOT i1JNxab05440 AT mx1 DOT redhat DOT com> <20040220001002 DOT GB24803 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040220001002.GB24803@redhat.com> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com 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 AT cygwin DOT 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/