stevetaylor999 wrote on Thu Jun 29 19:33:03 MEST 2006:
Hi, Apologies if this has been posted before. I’m having some problems debugging perl modules, if I step into a module the ActivePerl runtime crashes and exits. I downloaded a trial copy of Komodo to check if it is an issue with my code I do not see the same issue when running in debug with Komodo. I’ve built a very simple test just to eliminate any coding issues see below: --Start TestModule.pm package TestModule; use warnings; use strict; use Exporter; our $VERSION = "1.00.00"; our @ISA = qw(Exporter); our @EXPORT = (); our @EXPORT_OK = qw(func1 func2); our %EXPORT_TAGS = ( DEFAULT => [qw(&func1 &func2)]); sub func1 { return 1; } sub func2 { return 0; } 1; --End TestModule.pm --Start Test.pl #!perl use strict; use warnings; use TestModule qw(func1); func1(); TestModule::func2(); --End Test.pl If I attempt to step into func1 I get the following error ‘Perl Command Line Interpreter has encountered a problem and needs to close.’. I’m running ActivePerl 5.8.8 Build 817 with your PadWalker code, Windows XP SP2, Eclipse 3.1.2 and EPIC 0.3.12. Any help with this problem would be greatly appreciated. Thanks, Steve Taylor
jploski wrote on Thu Jun 29 20:13:12 MEST 2006:
It seems like a bug in the ActiveState version of Perl. I just tested your code under Linux without problems. If you wish, I can send you a transcript of the communication which takes place between EPIC and the debugger (perl -d). You might then be able to reproduce the bug without the Java part of EPIC (entering commands directly in a debugger session) and localize the bug even better. If it is reproducible and you discover an acceptable workaround, I would incorporate the fix into EPIC.
stevetaylor999 wrote on Thu Jun 29 20:24:18 MEST 2006:
Thanks for the very quick responce. Ok if you can send me the transcript I'm more than happy to give it a try but I'm a perl novice. Cheers Steve Taylor
stevetaylor999 wrote on Fri Jun 30 17:17:30 MEST 2006:
Hi, After spending quite some time trying to get this to work I’m going to have to give up, the problem only occurs when you use the ‘our’ keyword at the module level. If I use the pragma ‘use vars qw(…)’ then everything works fine. What I did find is that the reference to the module level variables declared with our that are passed into the dumpvar_epic::DumpElem are fouled up in some way. The actual crash happens when you try to access the $_[0] in the DumpElem sub. For instance adding a print $_[0] . “\nâ€; just to see what’s in there cause the crash. Thanks for your help on this. BTW I’m more than happy to test any suggestions that you might have. Cheers Steve Taylor
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.