Debugger in .5.33 & .6.0 hang and loose vars

p3sulliva wrote on Fri Apr 20 06:44:51 MEST 2007:

I was working on this project with no problems (Eclipse 3.2.1, Sun JDK 1.4.2.14,AS
Perl 5.8.8, Epic .4.2x)  then needing a break from debugging, I decide to
upgrade to Epic .5.33.

Now I can not debug and its not even consistant either. It will hang at
different point just about everytime except calling other Modules it always
hangs. So I updated to .6.0 to see if it like 3.2.1 better, basically the
same result. Both version, it runs if hit resume from the start with no
break points.

WinXP Sp2

Details of what hangs means:
1)Stack shows running:
somecodO.pl [Perl Local]	
	Perl Debugger	
		Main Thread	
	Perl Debugger	

BUT all the step in,step over,step return, etc... are greyed out except
Terminate

2) The Variables window goes from having a lot of info with lines to completely
blank white with NO lines.

3)But the back & forward buttons still work from a navigation stand point

jploski wrote on Sun Apr 22 22:11:15 MEST 2007:

Try out 0.5.34. It contains some blind fixes, as I was not able to reproduce
this problem so far in my environment.

p3sulliva wrote on Mon Apr 23 15:54:46 MEST 2007:

When will .5.34 be released?

p3sulliva wrote on Mon Apr 23 18:43:20 MEST 2007:

Also, How do I uninstall .6.0? I tried removing the .6 jars and folders
plus feature folder/jar but it disabled epic all together

jploski wrote on Mon Apr 23 19:05:55 MEST 2007:

0.5.34 was released yesterday.

To cleanly remove a feature in Eclipse, open Help/Software Updates/Manage
Configuration and then first disable the feature (Eclipse will ask for restart,
say yes). After the restart go back to "Help/Software Updates/Manage Configuration"
where you can uninstall the disabled feature (and optionally restart again).

Removing the folders/jars from disk as you did is also ok.

Both ways disable EPIC altogether - that's what removing the EPIC feature
is meant to do. To install 0.5.34 (as recommended), now enter the update
site http://e-p-i-c.sf.net/updates under "Help/Software Updates/Find and
Install.../Search for new features to install" and follow the on-screen
installation instructions.

ytchenak wrote on Mon May 21 15:59:29 MEST 2007:

I have install .5.35; the problem (it get random hang during debug step)
is still persistent.
I have eclipse 3.2.1, java 1.5.0_11-b03
... any ideas?

jploski wrote on Mon May 21 16:32:03 MEST 2007:

Switch to 0.6.4. The debugger code is different/more efficient than in 0.5.x.
The bug you are encountering might also be fixed there by chance.

mjscott2702 wrote on Mon Jun 11 20:25:09 MEST 2007:

I had a similar problem with 0.5.33 and 0.5.37, using PadWalker 1.0 from
ActiveState PPM, the debugger would hang at random lines in my script, especially
when calling methods in other modules.

I have installed EPIC 0.6.7 and DOWNGRADED PadWalker to 0.10, and everything
SEEMS to work - not sure which of those steps fixed my problem.

The EPIC web page states that the latest version of PadWalker should be
OK, and a custom version of this module is no longer supplied for ActiveState
installations. Is this truly the case?

Michael Scott

jploski wrote on Mon Jun 11 20:46:48 MEST 2007:

It would be useful if you could continue testing it with your current PadWalker
and then upgrade to 1.5 at some time. The debuggers in 0.5.x and 0.6.x are
not really comparable. There have been many thread synchronization-related
changes in the debugger code in 0.6.x, aimed at fixing the old, hard to
reproduce bugs. Some new bugs were introduced (no doubt), but such is the
price for reaching stability without an ability of extensive pre-release
testing (until recently there have been NO automated tests at all for the
debugger code and the situation is still far from ideal).

bgranvea wrote on Sat May 26 11:55:04 MEST 2007:

Hi,

I have the same problem as described: the debugger hangs randomly after
a few debug steps. I've tried with EPIC 0.6.4: same result.

I've noticed however that this happens only when debugging in CGI mode.
It seems to work fine for a standalone application.

My environment: WinXP2, JDK 1.6u1, Eclipse 3.2.2, EPIC 0.6.4, ActivePerl
5.8.8.819

mjscott2702 wrote on Tue Jun 12 00:57:41 MEST 2007:

I did find another problem in the debugger, using 0.6.7 and PadWalker versions
0.10 (current ActiveState repository version), 1.0 and 1.5 (from various
other repositories).

My script contains the following line:

@cfg = grep( !/^#|^\s*$/, <$cfg> );

where $cfg is a FileHandle scalar variable, designed to create an array
containing all the lines in said file which aren't "blank" or comment lines
(beginning with #).

After stepping through and executing this line, the variables tab shows
@cfg to be [].

However, subsequent code to process @cfg still works ok, and using the perl
debugger from the command line shows that @cfg actually contains 37 entries.

Any suggestions or things to try?

jploski wrote on Tue Jun 12 22:04:36 MEST 2007:

You could try renaming one of the $cfg variables. Also please file a bug
report with a small sample script and input file which I can use to reproduce
this problem.

Also see this bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=1734893&group_id=75859&atid=545274
It might be related.

mjscott2702 wrote on Wed Jun 13 05:57:21 MEST 2007:

I tried changing the open statement for the filehandle from:

open($cfg, "<", "config.txt");

to

open(CFG, "Script
open($cfg, "<", "config.txt");
@cfg = <$cfg>;
print "Line3 - length of \@cfg is ", scalar @cfg, "\n";
open($cfg, "<", "config.txt");
@config = <$cfg>;
print "Line6 - length of \@config is ", scalar @config, "\n";
open(CFG, ";
print "Line9 - length of \@cfg is ", scalar @cfg, "\n";
exit(0);

Variables Window
FileHandle(CFG) = 'fileno(8)'	
$cfg = GLOB(0x194404c)	
@cfg = []	
@config = []	

Console (STDOUT)
Line3 - length of @cfg is 3
Line6 - length of @config is 3
Line9 - length of @cfg is 3

Debugger From Command Line
C:\>perl -d config.pl

Loading DB routines from perl5db.pl version 1.28
main::(config.pl:1):    open($cfg, "<", "config.txt");

  DB<1> n
main::(config.pl:2):    @cfg = <$cfg>;

  DB<1> n
main::(config.pl:3):    print "Line3 - length of \@cfg is ", scalar @cfg,
"\n";

  DB<1> n
Line3 - length of @cfg is 3

  DB<1> X cfg
$cfg = GLOB(0x191b7d8)
   -> *main::$cfg
         FileHandle({*main::$cfg}) => fileno(7)
@cfg = (
   0  'This is line1'
   1  'This is line2'
   2  'This is line3'
)

jploski wrote on Wed Jun 13 19:06:09 MEST 2007:

Thanks for the sample code. It works correctly in 0.6.8 if you use lexical
variables. The problem (and a workaround) can be simply demonstrated as
follows:

@foo = (1,2,3)
# debugger in 0.6.8 shows an empty list -> bug

my @bar = (1,2,3);
# debugger in 0.6.8 shows correct list content

jploski wrote on Wed Jun 13 20:13:58 MEST 2007:

This bug is fixed in 0.6.9.

mjscott2702 wrote on Wed Jun 13 21:02:20 MEST 2007:

Wow, that was fast. Updated to 0.6.9 and now works correctly. Laziness on
my part for not using lexical variables. Thanks!