Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday November 14, 2005
02:54 PM

Scripting the Debugger

[ #27572 ]

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
use Some::Module::Which::I::Couldnt::Load::Until::Now
b Some::Module::Which::I::Couldnt::Load::Until::Now::unmunge
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 ... :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.
  • $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 exa


    -DA []

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

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

      -DA []

  • I haven't used it, but, it looks like it might help. []
    • 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."
  • 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 debugge