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 )

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.


Problem reports:
Unsubscribe info:

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