#401 can't display variables if any subroutines are present

open
Debugger (177)
7
2014-08-16
2007-05-31
Jack Tanner
No

Using Eclipse 3.2.2 on FC6. Start stepping through the code below, and when you step inside arf, the variable view changes to "An error occurred while dumping array content; contents of the Variables view may become invalid".

my $foo = 'bar';

arf($foo);

sub arf {
my $bar = shift;
print $bar;
}

(By the way, that error message is missing a period.)

Discussion

<< < 1 2 (Page 2 of 2)
  • Jack Tanner

    Jack Tanner - 2007-06-25

    Logged In: YES
    user_id=661682
    Originator: YES

    My system (Fedora 7) also reports SO_RCVBUF=87380 and SO_SNDBUF=16384. Note that this is on x86-64, but I originally encountered the bug on i386.

    I'm not sure if we'll learn anything that way, but it may possible to build a special perl5db.pl that sends out exactly what it receives.

    Could the problem lie at the other end? Should we make sure that EPIC is sending out what we think it's sending out?

     
  • Jan Ploski

    Jan Ploski - 2007-06-26

    Logged In: YES
    user_id=86907
    Originator: NO

    Ok, thanks for checking. You have already almost done what you propose regarding perl5db.pl. To be sure, you could also log the content of $buf right after the recv loop. Note that the problem is not in data not being sent, it is in the way how it is being sent (or received) - in several chunks per command instead of one large chunk.

    I also thought that the problem may be on the EPIC side (flushing the send buffer prematurely). However, as far as I can see from the code, the content is written to the buffer in one call to println and the PrintWriter is set to autoflush (after the println), so it should behave as expected.

    The next step in diagnosis will probably be to trace send/recv system calls from both the Java and perl5db.pl process (using strace or the like) in order to gain better understanding of what is going on.

     
  • Jan Ploski

    Jan Ploski - 2007-06-26

    Logged In: YES
    user_id=86907
    Originator: NO

    Another idea (which can be tried out quickly) is to increase the requested byte count from 2048 to something bigger like 16384 in perl5db.pl and see if it changes anything in the output log.

     
  • Jack Tanner

    Jack Tanner - 2007-06-26

    trace from hacked perl5db.pl with $buf

     
  • Jack Tanner

    Jack Tanner - 2007-06-26

    Logged In: YES
    user_id=661682
    Originator: YES

    I increased the byte count to 16384 and it changed nothing.

    I added logging of $buf in the recv loop, and the data are already truncated by the time they're in $buf. Log attached.

    Note that they're always truncated at the same point. Something deterministic is going on.

    Also, I wonder if somehow we're affected by the fact that the truncated chunk is inside a << variable.
    File Added: debug-log.txt

     
  • Jan Ploski

    Jan Ploski - 2007-06-26

    Logged In: YES
    user_id=86907
    Originator: NO

    I changed some things related to output buffering and flushing in 0.6.11, give it a try.

     
  • Jack Tanner

    Jack Tanner - 2007-06-26

    trace from perl5db.pl and EPIC 0.6.11

     
  • Jack Tanner

    Jack Tanner - 2007-06-26

    Logged In: YES
    user_id=661682
    Originator: YES

    The problem persists in 0.6.11. One thing that did change is that there's no longer a dialog alerting me to an exception not being handled. Log attached.
    File Added: debug-log.txt

     
  • Jan Ploski

    Jan Ploski - 2007-06-26

    Logged In: YES
    user_id=86907
    Originator: NO

    Do you use java from Sun or gcj?

     
  • Jack Tanner

    Jack Tanner - 2007-06-27

    Logged In: YES
    user_id=661682
    Originator: YES

    This is stock Fedora gcj-compiled Eclipse running w/ gcj. I could try to run with Sun's JVM.

     
  • Jack Tanner

    Jack Tanner - 2007-06-27

    Logged In: YES
    user_id=661682
    Originator: YES

    Well, whaddayaknow. Using Sun's JVM, the bug does not occur.

    Bingo! Thanks for all your help. I'm not even sure it's worthwhile to submit a bug against gcj, because that's going to get decomissioned pretty soon in favor of Sun's OpenJDK.

     
<< < 1 2 (Page 2 of 2)

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