Menu
▾
▴
#712 perl debugger crashes
Trying to step through a parsing routine, debugger crashes with weird error message {1 at ~.metadata/.plugins/org.epic.debug/perl5db.pl at line 8675}. Crash happens with memory grab as variable returned is copied to dom handle for XML::LibXML parser. Worked fine with small test file, now working with larger dataset from real client=>problems. Nothing in eclipse-workspace/.metadata/.log.
Windows 10, Eclipse 2020-03 (4.15.0), Strawberry 64-bit 5.22.3001, AdoptOpenJDK 8.0.252.09 x64, EPIC 0.7.7. Could it be something as simple as lack of memory for PadWalker (perhaps running in 32-bit space)? Have previously seen "PerlDebugJob has encountered a problem - An IOException occurred while executing debugger command" and workaround published here applied.
Thanks.
PadWalker 2.3, XML::LibXML 2.0205 (just updated a touch - no change).
Have you looked at what's in the perl5db.pl file (which EPIC derives from the one found in your Perl installation by applying a patch)? IIRC, perl5db.pl is overwritten each time when EPIC starts a debugging session, but you can copy it elseswhere and put that directory in front of the project's Perl include path so as to override it with your own version (and then insert into it some commands like debugging output to some file, to understand what's going on around that fatal "line 8675").
Haven't done that - looking at the perl5db.pl at that section it's their crash handler
{=head2 C<dbdie>
The debugger's own C<$SIG{DIE}> handler. Handles providing a stack trace
by loading C<carp> and calling C<carp::longmess()> to get it. We turn off
single stepping and tracing during the call to C<carp::longmess> to avoid
debugging it - we just want to use it.</carp::longmess></carp::longmess()></carp></dbdie>
If C<dielevel> is zero, we let the program being debugged handle the
exceptions. If it's 1, you get backtraces for any exception. If it's 2,
the debugger takes over all exception handling, printing a backtrace and
displaying the exception via its C<dbwarn()> routine.}</dbwarn()></dielevel>
If I understand, the crash is happening somewhere else and this code is merely catching the $SIG - even if not very informatively.
TBH, not really sure where to look next - the code has worked fine with smaller datasets so it's not just really bad coding on my part (although that's always possible). You are correct about there being two versions of perl5db.pl with the EPIC debug patch version significantly larger.
Appreciate the suggestion, thanks. Shall start exploring...
Last edit: Glenn Weavind 2020-07-01
Problem was at my end - better use of the tools fixed the issue. Please close.