X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4A608954.4040301@gmail.com> Date: Fri, 17 Jul 2009 15:23:16 +0100 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash ) References: <20090715185636 DOT GA16211 AT ednor DOT casa DOT cgf DOT cx> <4A5E2ED6 DOT 3070502 AT gmail DOT com> <20090715194539 DOT GZ27613 AT calimero DOT vinschen DOT de> <4A5E3F1F DOT 9040103 AT gmail DOT com> <20090716161219 DOT GP27613 AT calimero DOT vinschen DOT de> <4A5F59A1 DOT 1060902 AT gmail DOT com> <20090716195552 DOT GU27613 AT calimero DOT vinschen DOT de> <20090716211823 DOT GC22617 AT ednor DOT casa DOT cgf DOT cx> <20090717085727 DOT GW27613 AT calimero DOT vinschen DOT de> <4A607EE5 DOT 5050306 AT gmail DOT com> <20090717134114 DOT GX27613 AT calimero DOT vinschen DOT de> In-Reply-To: <20090717134114.GX27613@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Corinna Vinschen wrote: > On Jul 17 14:38, Dave Korn wrote: >> Corinna Vinschen wrote: >>> Assuming that skipping the OS handlers is OK, >> What if they are try....finally handlers rather than try....except? Bad >> things might happen? It might be useful to know what those functions are > > If you look again, you see that it's always the same address, always the > same default exception handler in ntdll.dll. I guess it might be more > correct to add another handler to the chain, rather than to strip the OS > handlers from the chain, but the fact that the OS SEH validity check was > happy with the chain and the testcase worked is kind of relaxing. I'm surprised. Whatever it was (presumably the part of the OS dynamic loader that is responsible for invoking DllMain) that put those two OS handlers at the front of the chain before we arrived in _cygwin_dll_entry AT 12() is liable to try and unlink them after we return, isn't it? Perhaps it has a bit of robustness code so it doesn't unlink them if the head pointer doesn't match what it's expecting. Hmm. > Do we have to take other handlers than the OS handlers and the Cygwin > handlers into account? Cygwin apps don't install SEH handlers, do > they? Or do C++ apps? Nope, they don't, but that will probably not be the case forever, there are (long-term) moves afoot to get SEH support into the compiler. However, we're in early startup-and-init here; we don't need to worry about what the application will do once it finally gets going. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple