Debugger angst

[Clint Olsen]

One of the things I can't stand about Perl is the debugger. It really
lacks compared to C debuggers, and I can't for the life of me figure out
why this has to be. Do most Perl programmers just use print to debug their
code?

When I get the runtime error 'Can't use string ("BLAH") as an ARRAY
ref...', the first thing you would expect is that the debugger stop
excution immediately so you can inspect what access caused the problem.
For example, in a multi-level data structure access, how can I tell which
particular access resulted in a violation?

$$hr{abc}[123][456] = $foo; # ????

Instead Perl bails out completely, so while the call stack is nice, that's
all you get!

Secondly, what's with the lack of ability to go up/down frames in the
stack? You can use 'T' to view the call stack, but in traditional
debuggers, you can view variables etc. at each stack frame to actually find
out /how/ you got into a particular predicament. So, I end up having to
put on my psychic hat to figure how how I /might/ have gotten there and
hope I can set a sensible breakpoint.

Thanks,

-Clint

 

[Dan Wilga]

One of the things I can't stand about Perl is the debugger. It really
lacks compared to C debuggers, and I can't for the life of me figure out
why this has to be. Do most Perl programmers just use print to debug their
code?

I agree that perl's debugger is a bit lacking, though not really very
much compared to gdb (ack, ptooey!).

There are a few graphical perl debuggers and IDEs that probably address
some of what you want:

http://sourceforge.net/projects/ddd/
http://sourceforge.net/projects/ptkdb/
http://sourceforge.net/projects/open-perl-ide/

However, if you're looking for commandline-only debugging, then I think
the answer you're going to get from most folks who read this newsgroup
is: perl's debugger is written in perl, and it's open source. So feel
free to develop a better one. ;-)

 

[Peter Scott]

One of the things I can't stand about Perl is the debugger. It really
lacks compared to C debuggers, and I can't for the life of me figure out
why this has to be. Do most Perl programmers just use print to debug their
code?

Some of us use the debugger quite a bit. Some of us have even
written books featuring it

When I get the runtime error 'Can't use string ("BLAH") as an ARRAY
ref...', the first thing you would expect is that the debugger stop
excution immediately so you can inspect what access caused the problem.
For example, in a multi-level data structure access, how can I tell which
particular access resulted in a violation?

$$hr{abc}[123][456] = $foo; # ????

Run it under the debugger again and set a breakpoint for that line.
You wouldn't want the overhead of the debugger on every execution,
would you?

Secondly, what's with the lack of ability to go up/down frames in the
stack? You can use 'T' to view the call stack, but in traditional
debuggers, you can view variables etc. at each stack frame to actually find
out /how/ you got into a particular predicament. So, I end up having to
put on my psychic hat to figure how how I /might/ have gotten there and
hope I can set a sensible breakpoint.

Which is why I developed the 'y' command which allows you to inspect
lexicals at higher stack frames. perldoc perldebug.

 

[Clint Olsen]

$$hr{abc}[123][456] = $foo; # ????

Run it under the debugger again and set a breakpoint for that line.
You wouldn't want the overhead of the debugger on every execution,
would you?

Of course not. But if I'm running the code in the debugger, I've already
accepted the overhead. Trap the problem, and allow the user to inspect the
data that's there. Don't unroll and bail out on me...

The line I showed above only failed under certain conditions. This happens
in Perl all the time. So, just setting a breakpoint does nothing. I could
succeed hundreds of times on this line. Coming up with the condition can
be really irritating in a situation like this:

$foo = $$hr{abc}[123]{def}[456]; # one level is undef, which one?

So, in a multidimensional hash/array access, just telling me an array or
hash was 'undef' doesn't tell me a whole lot. Since Perl has runtime type
checking, it would seem that it should be able to tell me /which/ thingy
was malformed.

Which is why I developed the 'y' command which allows you to inspect
lexicals at higher stack frames. perldoc perldebug.

Ok, I'll install PadWalker and see if I can make this thing work for me.

Thanks,

-Clint

 

[Clint Olsen]

I agree that perl's debugger is a bit lacking, though not really very
much compared to gdb (ack, ptooey!).

I would sure like to know where you think gdb is lacking in capability. I
think the end-all of capabilties in gdb is [hardware] watchpoints. Either
I don't understand how watches workin Perl or they are abysmal. Every time
an object goes out of scope I get a notice that the value of a particular
object has changed. This is especially common in scripts not using
file-scoped lexicals. I've tried dereferencing an object so I could
actually look at the actual object in question, but it doesn't seem to
help.

http://sourceforge.net/projects/ddd/
http://sourceforge.net/projects/ptkdb/
http://sourceforge.net/projects/open-perl-ide/

Thanks for the links. I'll check them out. Although my preference would
be for a graphical debugger that actually did not wrap around Perl's
command-line debugger. The user interface is pretty terse.

Thanks,

-Clint

 

[Clint Olsen]

Which is why I developed the 'y' command which allows you to inspect
lexicals at higher stack frames. perldoc perldebug.

Ok, I managed to get this installed, and here are my thoughts on this:

1) Since 'T' doesn't print out the numbers of the stack frames, I end up
using 'wc -l' to calculate my 'uplevel'. This is really annoying.

2) This command (and apparently 'X' and 'Y') don't take qualified type
names or references to such, just the literal text name. Why? So, if I
wanted to inspect a multi-level data structure (array, hash, or
whatever), I either get all or none of it. In our case, that was about
1/4 mi. of text

3) 'y' and friends don't have a depth limit so you don't get the reams of
data mentioned in #2.

On another completely independent gripe:

Why doesn't the perl debugger take File:line input as debug points? Every
time I have to type "f Package.pm" and "b lineno", it's very aggravating.

Don't get my wrong, 'y' is a big improvement over what I had before -
zip/nada for peeking at the stack. I just wanted to point out some usage
model issues that could use some refinement.

It would be interesting if you could interject on the effort involved on
any of these points. I'd even consider trying to add them with my fumble
fingers if it was feasible. I either need to do that or get the heck out
of using Perl.

-Clint

 

[Peter Scott]

Ok, I managed to get this installed, and here are my thoughts on this:

1) Since 'T' doesn't print out the numbers of the stack frames, I end up
using 'wc -l' to calculate my 'uplevel'. This is really annoying.
Agreed.

2) This command (and apparently 'X' and 'Y') don't take qualified type
names or references to such, just the literal text name. Why? So, if I
wanted to inspect a multi-level data structure (array, hash, or
whatever), I either get all or none of it. In our case, that was about
1/4 mi. of text

'y' was intended as an analog to 'V' and 'X', which were already defined as
ways of scanning a package for particular variables. For inspecting an
arbitrary expression, 'x' is your friend. Unfortunately, 'x' can't jump
scoping levels.

3) 'y' and friends don't have a depth limit so you don't get the reams of
data mentioned in #2.

On another completely independent gripe:

Why doesn't the perl debugger take File:line input as debug points? Every
time I have to type "f Package.pm" and "b lineno", it's very aggravating.

Agreed, but you can usually set a breakpoint for the subroutine in Package.pm,
or in some other way wait until you get to that file before setting the
breakpoint. I have wanted the feature you suggest, but not very strongly.
As to 'why', see below.

Don't get my wrong, 'y' is a big improvement over what I had before -
zip/nada for peeking at the stack. I just wanted to point out some usage
model issues that could use some refinement.

It would be interesting if you could interject on the effort involved on
any of these points. I'd even consider trying to add them with my fumble
fingers if it was feasible. I either need to do that or get the heck out
of using Perl.

The reason the features you request aren't in the debugger is best explained
by the fact that it is a tortuous mess of incomprehensible code with a creaky
legacy user interface. Only a few brave souls in recent years have had the
inclination and the courage to attempt to modify it. I was responsible only
for minuscule modifications. Most people these days are waiting for Mark
Jason Dominus' rewrite, schedule unknown to me.

If you wanted to attempt any of those changes, the one that might be doable
without encountering insanity in the process is qualifying line number
breakpoints with filenames. No guarantee, though.