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 Thu, Jul 16, 2009 at 06:12:20PM +0200, Corinna Vinschen wrote:
>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?

I don't have the output in front of me but I saw something that had three things
in the chain.  The first was ours, the second was an OS function which
seemed somehow thread related, the third looked bogus but not bogus like
the above.

cgf

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