Scripting the Debugger

Ovid on 2005-11-14T19:54:44

Sometimes you just have to use the debugger and it's annoying when that happens. Why? Because sometimes the problem is buried deep in some module and you have no idea where, so you find yourself repeatedly restarting the debugger and typing this:

b 91
c
s
use Some::Module::Which::I::Couldnt::Load::Until::Now
b Some::Module::Which::I::Couldnt::Load::Until::Now::unmunge
c

x $value
... and so on

And you keep rerunning that, refining the commands as you go along and realize you're getting closer to your goal (or you use the 't' option and let it run until done). That gets old very fast. Is there some way to script that? Maybe tell the debugger to load a series of commands or something? It doesn't seem like this should be too hard (though the debugger internals are horrifying). If this currently cannot be done and someone wants to write a patch so I don't have to ... :)


perldebug

jmm on 2005-11-14T20:12:24

Take a look at perldebug, looking at the debugger customization section, where it talks about using a .perldb file, and setting a afterinit function that pushes lines onto @DB::typeahead.

Re:perldebug

jweveland on 2005-11-15T16:26:14

Joe has done an amazing amount of documentation on this, and also has a very good presentation which I stumbled onto recently.

debugger

da on 2005-11-14T20:29:51

$DB::single = 1; could be inserted into the module code for Some::Module::... to stop it at the right point.

I've done the lazy version of a script, copy-and-paste 20 lines of debugger commands at a time to re-run them. It's inelegant, but like you, I took a look at the debugger code and averted my eyes :) However, I just took a glance at perldebug, and it says:

       You can mock TTY input to debugger by adding arbitrary commands to
       @DB::typeahead. For example, your .perldb file might contain:

           sub afterinit { push @DB::typeahead, "b 4", "b 6"; }

       Which would attempt to set breakpoints on lines 4 and 6 immediately
       after debugger initilization. Note that @DB::typeahead is not a sup-
       ported interface and is subject to change in future releases.
I'm curious how well that works.

Re:debugger

da on 2005-11-14T21:24:17

in 2003, mjd worked on the debugger under a perl foundation grant, which was to include a deliverable of a refactored debugger.

http://www.perlfoundation.org/gc/grants/2003_q4.html

That would be very, very, cool if the code were available for hacking on... I haven't been able to find it, in quick google searches; I suppose I should email mjd. :)

devel::ebug?

kennyg on 2005-11-14T21:19:10

I haven't used it, but, it looks like it might help. http://search.cpan.org/user/lbrocard/Devel-ebug-0.45/

Re:devel::ebug?

link on 2005-11-14T22:33:19

Devel::ebug supports undo

"The undo method undos the last action. It accomplishes this by restarting the process and passing (almost) all the previous commands to it. Note that commands which do not change state are ignored. Commands that change state are: break_point, break_point_delete, break_point_subroutine, eval, next, step, return, run and watch_point."

source

pemungkah on 2005-11-15T20:20:14

If you type 'h source' in the 5.8 debugger, you'll see

source file Execute file containing debugger commands (may nest).

So you don't need to do anything. Just put the commands you want into some file and then source file.

If you want to actually write new debugger commands, take a look at Devel::Command: it lets you write Devel::Command::XXX modules to create a new 'xxx' command. Devel::Command::Viz, for instance, lets you use GraphViz::Data::Structure to visualize objects in dotty from inside the debugger (which what I wanted to do when I started down the trail of commenting the debugger back in 2002...).