This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on 1.5.25 = instant crash )


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]