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
