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

open
Jan Ploski
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 3 4 > >> (Page 3 of 4)
  • Jack Tanner
    Jack Tanner
    2007-06-25

    trace from hacked perl5db.pl

     
    Attachments
  • Jack Tanner
    Jack Tanner
    2007-06-25

    Logged In: YES
    user_id=661682
    Originator: YES

    The bug still exists with EPIC 0.6.10 under Eclipse 3.2.2 on Fedora 7. I attach a trace from a hacked perl5db.pl. The hack itself was to add this code at perl5db.pl line 622

    open (my $debug_fh, '>>', '/tmp/debug-log.txt');
    print $debug_fh "USERCONTEXT:\n$usercontext\n";
    print $debug_fh "EVALARG:\n$evalarg\n\n";
    close $debug_fh;

    File Added: debug-log.txt

     
  • Jan Ploski
    Jan Ploski
    2007-06-25

    Logged In: YES
    user_id=86907
    Originator: NO

    I think the problem lies in this loop located in perl5db.pl's sub readline:

    do {
    $IN->recv( $buf = '', 2048 ); # XXX "what's wrong with sysread?"
    # XXX Don't know. You tell me.
    } while length $buf and ($stuff .= $buf) !~ /\n/;

    It is supposed to "receive anything there is to receive"... However, it does not in your case receive the whole command string from EPIC and hence the subsequent eval of an incomplete block then causes errors. I see no way of fixing this loop to always reliably read the whole input from EPIC in principle - there is no terminator token which EPIC sends to indicate that it's done. Anyway, it is strange that the recv call returns after reading some 200 bytes in your case. The send and receive buffers for TCP sockets should be much larger than that.

    I'm attaching a simple script check_tcpbuf.pl which you can run to find out the size of the default TCP socket send/receive buffers on your system. When you run it, it will first print out the buffer sizes for a server socket, then it will start listening for a TCP connection on localhost:5001 (which you can establish using telnet or netcat), finally it will print out the buffer sizes for the client connection. For example, my system reports SO_RCVBUF=87380 and SO_SNDBUF=16384, which is more than necessary to accomodate the longest EPIC debugger command without splitting it into pieces on receive.

     
  • Jan Ploski
    Jan Ploski
    2007-06-25

    Script to find out SO_SNDBUF, SO_RCVBUF

     
    Attachments
  • Jan Ploski
    Jan Ploski
    2007-06-25

    Logged In: YES
    user_id=86907
    Originator: NO

    File Added: check_tcpbuf.pl

     
  • 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

     
    Attachments
  • 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

     
<< < 1 2 3 4 > >> (Page 3 of 4)