X-Recipient: archive-cygwin@delorie.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: <4A5F59A1.1060902@gmail.com> Date: Thu, 16 Jul 2009 17:47:29 +0100 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash ) References: <20090715000331.GA5635@ednor.casa.cgf.cx> <6D01817BC10A4430AFE7A590CC935C09@multiplay.co.uk> <20090715152139.GA694@calimero.vinschen.de> <4A5DFDDF.2000904@gmail.com> <20090715162243.GL14502@ednor.casa.cgf.cx> <4A5E0AB1.9020201@gmail.com> <20090715185636.GA16211@ednor.casa.cgf.cx> <4A5E2ED6.3070502@gmail.com> <20090715194539.GZ27613@calimero.vinschen.de> <4A5E3F1F.9040103@gmail.com> <20090716161219.GP27613@calimero.vinschen.de> In-Reply-To: <20090716161219.GP27613@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Corinna Vinschen wrote: > And that's what I get in the Perl testcase: > > (gdb) x/xw 0x7efdd000 > 0x7efdd000: 0x0088ce68 > (gdb) x/2xw 0x0088ce68 > 0x88ce68: 0x0088400c 0x6103ce20 <-- Cygwin exception handler > (gdb) x/2xw 0x0088400c > 0x88400c: 0x00000000 0x00000001 <-- Huh? > > This looks wrong, doesn't it? The question is now, how and why does > that happen? > Where's the 0x00000000 pointer coming from on 2008? Is it possible that > the OS overwrote the entry because it appears to be an address in Perl's > stack, so it's a potential security theat? The addresses are in the wrong order; SEH registration records should always nest in the same way as stack call frames, i.e. unwinding toward ascending memory addresses, but the second record is at a lower address than the first, so the chain has been mangled somehow. Perhaps that breaks an integrity check in the kernel? Where actually is $esp at the time; is the bogus one in an already-released frame below $esp? You might want to try again with a watchpoint: watch *(unsigned int*)0x88ce68 ... and see how and where that head entry gets set up and whether it subsequently gets overwritten somehow. 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