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: <4A5F59A1.1060902@gmail.com>
Date: Thu, 16 Jul 2009 17:47:29 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
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: <20090715000331 DOT GA5635 AT ednor DOT casa DOT cgf DOT cx> <6D01817BC10A4430AFE7A590CC935C09 AT multiplay DOT co DOT uk> <20090715152139 DOT GA694 AT calimero DOT vinschen DOT de> <4A5DFDDF DOT 2000904 AT gmail DOT com> <20090715162243 DOT GL14502 AT ednor DOT casa DOT cgf DOT cx> <4A5E0AB1 DOT 9020201 AT gmail DOT com> <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>
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 AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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:

> 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