Crash stepping into functions

gfick wrote on Tue Dec 19 15:29:40 CET 2006:
HI:

I've gotten EPIC to work well for debugging within a single file. I can
inspect variables, step through code, set breakpoint, etc. However, I've
never been able to step into functions located in another file (*.pm). This
always crashes for me, and has since I first started using EPIC (~5 months
ago). I get the standard windows crash dialog, telling me the Perl Command
Line Interpreter has crashed (perl.exe). If I click debug, I get an unhandled
exception error.

I am currently using the latest EPIC testing (0.5.25), but I've seen the
same behavior using 0.5.0, 0.5.10, 0.5.16. I am using PadWalker 0.10, and
ActiveState Perl 5.8.8.819. I am running WindowsXP.

This seems like a problem with ActiveState Perl, but has anyone had this
problem before?

jploski wrote on Tue Dec 19 18:29:11 CET 2006:
I vaguely remember seeing crashes of perl.exe during debugging in the past.
However, I no longer encounter these problems under Windows XP, using the
same version of ActiveState Perl you mentioned.

Is your code multithreaded? (just a wild guess)

If you can reproduce the problem easily in EPIC, then you should also attempt
to reproduce it without EPIC. Turn on the option "Perl debugger console"
in EPIC Preferences. Another item will then appear in the Debug view and
you will see the actual communication going on between EPIC and perl.exe
in the Console view when you click on it. Furthermore, the command line
used to invoke the perl.exe process and the values of environment variables
will be logged in the Error Log view (or in the $WORKSPACE/.metadata/.log
file).

You should first attempt to replay the debug session on the command line,
ignoring the environment variables (particularly ignoring PERLDB_OPTS).
This kind of test is fast and easy to setup. If you fail to reproduce the
problem, the environment including PERLDB_OPTS shouuld be included as well
(you should then substitute something like netcat for EPIC in order to control
the debugger manually from another process).

Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.