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

Dave Korn dave.korn.cygwin@googlemail.com
Thu Jul 16 17:00:00 GMT 2009


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



More information about the Cygwin mailing list