Debugger in .5.33 & .6.0 hang and loose vars

Help
2007-04-20
2013-05-20
  • Patrick Sullivan

    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   
            <running>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

     
    • Jan Ploski

      Jan Ploski - 2007-04-22

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

       
      • Patrick Sullivan

        When will .5.34 be released?

         
        • Patrick Sullivan

          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

           
          • Jan Ploski

            Jan Ploski - 2007-04-23

            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.

             
    • Anonymous - 2007-05-21

      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?

       
      • Jan Ploski

        Jan Ploski - 2007-05-21

        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.

         
      • Michael Scott

        Michael Scott - 2007-06-11

        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

         
        • Jan Ploski

          Jan Ploski - 2007-06-11

          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).

           
    • Boris Granveaud

      Boris Granveaud - 2007-05-26

      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

       
    • Michael Scott

      Michael Scott - 2007-06-11

      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?

       
    • Michael Scott

      Michael Scott - 2007-06-13

      I tried changing the open statement for the filehandle from:

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

      to

      open(CFG, "<config.txt");

      but still the same result (@cfg is displayed as []). Changing the name of the fileref to $cfgFile (so that the names of the scalar fileref and array to read the file into are different) - again, @cfg is displayed as empty.

      Using the following script and data file, the @cfg and @config arrays are always displayed as being empty, as shown by copying the contents of the Variables pane.

      <b>Script</b>
      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, "<config.txt");
      @cfg = <CFG>;
      print "Line9 - length of \@cfg is ", scalar @cfg, "\n";
      exit(0);

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

      <b>Console (STDOUT)</b>
      Line3 - length of @cfg is 3
      Line6 - length of @config is 3
      Line9 - length of @cfg is 3

      <b>Debugger From Command Line</b>
      C:\&gt;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'
      )

       
      • Jan Ploski

        Jan Ploski - 2007-06-13

        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

         
      • Jan Ploski

        Jan Ploski - 2007-06-13

        This bug is fixed in 0.6.9.

         
        • Michael Scott

          Michael Scott - 2007-06-13

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

           

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks