I've successfully used Perl EPIC's debugger with Eclipse 3.7 before, but upgraded to Eclipse Kepler some months ago and didn't need to debug any Perl since then, until today. And today EPIC is ignoring some of my breakpoints with the following output:
[Tue Sep 16 15:05:37 2014] perl5db.pl:640]: Use of uninitialized value $path in hash element at [...]/epic_breakpoints.pm line 73, <DATA> line 429.
[Tue Sep 16 15:05:37 2014] perl5db.pl:640]: Use of uninitialized value $path in pattern match (m//) at C:/Program Files/Perl/lib/Cwd.pm line 627, <DATA> line 429.
[Tue Sep 16 15:05:37 2014] perl5db.pl:640]: Use of uninitialized value in string ne at [...]/epic_breakpoints.pm line 94, <DATA> line 429.
Please not that this is NOT the well known Cwd.pm problem documented for Windows, but instead it seems that adding breakpoints itself doesn't work anymore. The relevant code from the mentioned epic_breakpoints.pm is the following:
8: use Cwd 'abs_path';
36: sub add_breakpoint
37: {
38: eval { _add_breakpoint(@_); };
39: # note/TODO: $@ ne '' here if the line was not breakable
40: }
69: sub _abs_path
70: {
71: my $path = shift;
72:
73: my $cached = $abs_path_cache{$path};
74: return $cached if $cached;
75:
76: eval { $cached = $abs_path_cache{$path} = abs_path($path); };
77: return defined($cached) ? $cached : $path;
78: }
79:
80: sub _add_breakpoint
81: {
82: my $source_path = _abs_path(_trim(shift));
[...]
The problem seems to be that $path is undefined, which shouldn't be the case of course. I activated the debugger console of EPIC and got the following output:
Loading DB routines from perl5db.pl version 1.33
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
Attribute::Handlers::CODE(0x29c75e8)(C:/Program Files/Perl/lib/Attribute/Handlers.pm:246):
246: $global_phase++;
DB<1> printf $DB::OUT "%vd", $^V;
5.14.4
DB<2> print $DB::OUT eval { require PadWalker; PadWalker->VERSION(0.08) }
1.96
DB<3> ;{
my $file = <<'EOT';
C:/Users/tschoening/Documents/Eclipse/Perl/Perl-Bibliotheken/stmodul/amsoft_warn_filter.pm
EOT
my $line = <<'EOT';
106
EOT
my $cond = '';
epic_breakpoints::add_breakpoint($file, $line, $cond);
};
Obviously the debugger seems to get usable paths and is calling the proper function, but somehow it looks like the provided args don't pass through anymore. EPIC seems to have the bad behaviour of always extracting epic_breakpoints.pm from it's Eclipse bundle, therefore I don't seem to be able to debug add_breakpoint and what args are provided, if any.
The interesting part now is that some really trivial Perl test files I have, without any packages or such, just some bunch of Perl lines, can still be successfully debugged including added break points. So in general the debugging should work and this again shows that I don't suffer of the Cwd.pm problem.
Do you have any idea on what I'm might doing wrong in my Perl packages which somehow seem to interfere with the debugging code? Anything I could have done to general args handling for eval or such? The app I would like to debug is somewhat large and I currently have no idea what to look after, therefore I would appreciative any hint you might provide for what I should look after.
Thanks!
I've tested a bit more and strangely the behaviour changed a bit: I somehow managed to execute the program I wanted to debug without the error occurring, only to see it occurred again later within the debug session after multiple added breakpoints. Don't take me wrong: I've successfully managed to add some breakpoints and after some addition ones the error reoccured for some reason. Seems like it sometimes occurres right from the start if a break point has been added before and if not it depends on some number of added breakpoints during the debug session.
After some trial and error for newly added code it looked to me the following two lines introduced the problem:
require CGI::Carp;
CGI::Carp->import('fatalsToBrowser');
I could reproduce that the error only occurred if those two lines are in place. At least at the beginning, some time later I couldn't reproduce the error even with those lines in place. Additionally I'm registering some WARN handler with a anonymous sub reference in which I'm shifting args, which I thought would maybe influence anything as well, but that doesn't seem to hold because it's working now and worked before with only the above tow lines commented.
Strange things happen sometimes, as it's working now, I will ignore this problem. :-)