Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
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
03: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
c
s
use Some::Module::Which::I::Couldnt::Load::Until::Now
b Some::Module::Which::I::Couldnt::Load::Until::Now::unmunge
c
<CR>
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 ... :)


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Scripting the Debugger 7 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
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 [coder.com]

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

      -DA [coder.com]

  • I haven't used it, but, it looks like it might help. http://search.cpan.org/~lbrocard/Devel-ebug-0.45/ [cpan.org]
    • 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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.