X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 16 Jul 2009 18:12:20 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
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 )
Message-ID: <20090716161219.GP27613@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A5E3F1F.9040103@gmail.com>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Jul 15 21:42, Dave Korn wrote:
> ... get the head pointer:
> 
> (gdb) x/xw 0x7ffde000
> 0x7ffde000:     0x0022ce68
> 
> ... on the stack, as you might expect, and walk the chain, first word of each
> record is the 'next' pointer, second is the handler function:
> 
> (gdb) x/2xw 0x0022ce68
> 0x22ce68:       0x0022ffe0      0x61028770
> (gdb) x 0x61028770
> 0x61028770 <_ZN7_cygtls17handle_exceptionsEP17_EXCEPTION_RECORDP15_exception_lis
> tP8_CONTEXTPv>: 0x57e58955
> (gdb) x/2xw 0x0022ffe0
> 0x22ffe0:       0xffffffff      0x7c4ff0b4
> (gdb) x 0x7c4ff0b4
> 0x7c4ff0b4 <SetProcessPriorityBoost+86>:        0x83ec8b55
> (gdb)
> 
>   0xffffffff in the chain pointer means final entry, and 0x7c4ff0b4 is
> somewhere in kernel32.dll, it's presumably the last resort fault handler.  The
> important point was we verified that the cygwin exception handler is first in
> the chain, so we'd expect it to be called by the NULL dereference (set a
> breakpoint there too, just in case something goes wrong shortly after it
> enters) when we step into it.  If there was something else first, we'd know
> where to start looking, if not, we'd have to suspect the OS has decided not to
> call the SEH chain at all for some reason.

Thanks again for your help.  I had the funny idea to examine the
SEH chain before the myfault handler gets installed.  That's what
I get in my C testcase:

  (gdb) x/xw 0x7efdd000
  0x7efdd000:     0x0028ce68
  (gdb) x/2xw 0x0028ce68
  0x28ce68:       0x0028ffc4      0x6103ce20   <-- Cygwin exception handler
  tP8_CONTEXTPv>: 0x57e58955
  (gdb) x/2xw 0x0028ffc4
  0x28ffc4:       0x0028ffe4      0x77cc03dd   <-- OS
  (gdb) x/2xw 0x0028ffe4
  0x28ffe4:       0xffffffff      0x77d16900   <-- OS

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?

Examining the SEH chain on Windows XP in the same situation looks quite
different, though not necessarily correct:

  (gdb) x/xw 0x7ffdd000
  0x7ffdd000:     0x0082ce68
  (gdb) x/2w 0x0082ce68
  0x82ce68:       0x00823c48      0x6103ce20   <-- Cygwin exception handler
  (gdb) x/2w 0x00823c48
  0x823c48:       0x00823ef4      0x7c90e920   <-- OS
  (gdb) x/2w 0x00823ef4
  0x823ef4:       0x0082419c      0x00823ee8   <-- Perl?!?
  (gdb) x/2w 0x0082419c
  0x82419c:       0x610e207f      0x6117194c   <-- ?!?
  (gdb) x/2w 0x610e207f
  0x610e207f <_ZN4muto7acquireEm+155>:    0x0674c085      0x01e345c6
  (gdb) x/2w 0x0674c085
  0x674c085:      Cannot access memory at address 0x674c085

Something's fishy.  However, it seems to work on XP and other systems.
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?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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