Re: Can't trigger system debugger to dump core when Cygwin's Perl launches program with backticks

[bulk88]

I have registered a perl script as crash handler with the operating system

I am curious, how did you do that?

The problem: When I use Cygwin’s Perl implementation, the program crash never triggers the crash handler. My suspicion is that Perl is catching the problem and silently dropping it. All works fine with a Perl from ActiveState.
......................
Also, if I start Crasher.exe directly in Cygwin’s shell, the crash handler is not called; neither is it called if started via backticks in either Cygwin or ActriveState Perl.

So when crasher is launched from AS Perl, does the crash handler get called? The 2 paragraphs are contradictory.

Be aware, that on Cygwin, Cygwin executables will never "crash" with a popup. They generate SIGSEGV/SIGBUS signals. I dont know what happens when a Win32 executable launched from Cygwin crashes.

Update: the logic of what to run when an app crashes lives in a key called HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug and value called "Debugger". I am using 32 bit Windows for this discussion. Debugger value is queried from _UnhandledExceptionFilter@4 which is in kernel32.dll. The ReactOS version is more simple than on real Windows, and says DPRINT1("Debugging is not implemented yet\n");. Using VS Debugger, you will normally never see _UnhandledExceptionFilter@4 unless you put a breakpoint at its very beginning because when a crash happens, it DOESNT catch the crash if there is a debugger attached to the process and passes the SEH exception to the next handler by returning EXCEPTION_CONTINUE_SEARCH, and there is none except for the VS debugger.

The callstack that gives the popup (the ok or cancel popup window actually is owned by csrss.exe) after stepping _UnhandledExceptionFilter and tricking it to think there is no C debugger attached to the process. kernel32.dll!_BaseProcessStart@4()  + 0x29a68 is the SEH catch block for BaseProcessStart.

     ntdll.dll!_NtRaiseHardError@24()  + 0x12 bytes    
     kernel32.dll!_UnhandledExceptionFilter@4()  + 0x51a bytes    
     kernel32.dll!_BaseProcessStart@4()  + 0x29a68 bytes    
     kernel32.dll!__except_handler3()  + 0x61 bytes    
     ntdll.dll!ExecuteHandler2@20()  + 0x26 bytes    
     ntdll.dll!ExecuteHandler@20()  + 0x24 bytes    
     ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xe bytes    
     msvcrt.dll!_memmove()  + 0x130 bytes    
>    perl512.dll!Perl_sv_setpvn(interpreter * my_perl=0x002c6eac, sv *
+ const sv=0x002ca9f4, const char * const ptr=0x00000006, const unsign
+ed int len=5)  Line 4345    C
     perl512.dll!Perl_newSVpvn_flags(interpreter * my_perl=0x002c6eac,
+ const char * const s=0x00000006, const unsigned int len=5, const uns
+igned long flags=524288)  Line 7711    C
     perl512.dll!S_unpack_rec(interpreter * my_perl=0x002c6eac, tempsy
+m * symptr=0x0245fa8c, const char * s=0x03b95e00, const char * strbeg
+=0x03b95dfc, const char * strend=0x03b95e04, const char * * new_s=0x0
+0000000)  Line 2051 + 0x15 bytes    C
     perl512.dll!Perl_unpackstring(interpreter * my_perl=0x002c6eac, c
+onst char * pat=0x03b9616c, const char * patend=0x03b96170, const cha
+r * s=0x03b95dfc, const char * strend=0x03b95e04, unsigned long flags
+=16)  Line 1221 + 0x2d bytes    C
     perl512.dll!Perl_pp_unpack(interpreter * my_perl=0x00000002)  Lin
+e 2284    C
     perl512.dll!Perl_runops_standard(interpreter * my_perl=0x002c6eac
+)  Line 38 + 0xc bytes    C
     perl512.dll!S_run_body(interpreter * my_perl=0x002c6eac, long old
+scope=1)  Line 2309 + 0x7 bytes    C
     perl512.dll!perl_run(interpreter * my_perl=0x002c6eac)  Line 2234
+ + 0xa bytes    C
     perl512.dll!RunPerl(int argc=3, char * * argv=0x002c2d50, char * 
+* env=0x012c30b8)  Line 270 + 0x6 bytes    C++
     perl.exe!main(int argc=3, char * * argv=0x002c2d50, char * * env=
+0x002c30b8)  Line 22 + 0x12 bytes    C
     perl.exe!_mainCRTStartup()  + 0xe3 bytes    
     kernel32.dll!_BaseProcessStart@4()  + 0x28 bytes

The event handle passed on the command line to the debugger is to keep around the crashed process. When that event handle becomes signaled, UnhandledExceptionFilter cleans up its resources and returns EXCEPTION_CONTINUE_SEARCH. I'll guess otherwise the crashed process will exit before the new C debugger process can register itself with Windows and get a handle to the crashed process to keep it alive.

Also welcome to perlmonks. I see you've taken 9 years to make your first post.

[jimcant]

Thanks for the helpful reply; knowing how Cygwin programs die (with SEGV etc.) may be the key. Perhaps I can catch the problem in a signal handler; getting the PID of the failed program would be the next hurdle. As far as the 2 contradictory paragraphs, the first refers to behavior in a good old reliable DOS console window; the latter refers to a Cygwin shell. The scenario going on in the kernel was enlighting Thanks again.