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
