Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
The stupid question is the question not asked
 
PerlMonks  

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

by jimcant (Initiate)
on Sep 14, 2013 at 13:46 UTC ( #1054111=perlquestion: print w/ replies, xml ) Need Help??
jimcant has asked for the wisdom of the Perl Monks concerning the following question:

I have scripts that launch arbitrary processes using backticks. Occasionally, a crash will occur (zero divide, for example) and need to get a core dump for analysis when that happens.

I have registered a perl script as crash handler with the operating system (this in Windows 7 – I knew you wanted to know) which gets called with the PID of the crash; the handler attaches Microsoft’s ‘cdb’ debugger which creates the needed dump. My test ‘crasher’ program is a C++ executable that does a divide-by-zero (Crasher.exe).

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.

The Question: How can I get Cygwin’s Perl to get out of the way and let the error propagate all the way back to the system.

Here’s an example that uses ActiveState perl that triggers the crash handler and produces a core dump
 C:> \tools\Perl\bin\perl.exe -e "`Crasher.exe`;"
But using Cygwin does not
C:> \cygwin\bin\perl.exe -e "`Crasher.exe`;"

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.

I thank you in advance for any help or suggestions!.

Comment on Can't trigger system debugger to dump core when Cygwin's Perl launches program with backticks
Select or Download Code
Re: Can't trigger system debugger to dump core when Cygwin's Perl launches program with backticks
by Anonymous Monk on Sep 15, 2013 at 02:19 UTC
Re: Can't trigger system debugger to dump core when Cygwin's Perl launches program with backticks
by bulk88 (Priest) on Sep 15, 2013 at 03:22 UTC
    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.
      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1054111]
Approved by Corion
Front-paged by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (9)
As of 2014-04-17 01:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (437 votes), past polls