Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have perl scripts that are deployed across many users in our group. The scripts have very strict error checking (any perl warning or error will cause an abort). Because the scripts are run by many different users, we occasionally have issues that are not reproducible by the developers due to interactions with the user's environment (running in Linux).

The error handler unwinds the stack (much like Carp), sends an email and then exists.

When our error-handler is triggered, I would like to be able to do the equivalent of generating a core-file that I could reload in the perl debugger at a later time to investigate variables, and debug exactly what is going on. I don't think that actually generating a core file wouldn't help, as bringing it up in gdb would not give me any reasonable way of debugging the variables as far as I know

Is there any mechanism that could achieve this? It would probably be fine to dump all variables/hashes/arrays in memory to a file, but as we have lots of modules, and many of them have local (my) variables, I am not aware of any mechanism to achieve that either.
  • Comment on Equivalent of a core-dump to restart perl script in debugger

Replies are listed 'Best First'.
Re: Equivalent of a core-dump to restart perl script in debugger
by LanX (Saint) on Dec 13, 2012 at 23:09 UTC
    > It would probably be fine to dump all variables/hashes/arrays in memory to a file, but as we have lots of modules, and many of them have local (my) variables, I am not aware of any mechanism to achieve that either.

    I'm not aware of general solution, did you already check CPAN and the debugger-docs? (I didn't yet)

    Anyway using Data::Dumper on the package STASHs should help logging global vars. Regarding lexical vars PadWalker can certainly help to inspect them.

    Cheers Rolf

Re: Equivalent of a core-dump to restart perl script in debugger
by Anonymous Monk on Dec 14, 2012 at 08:35 UTC