Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #74362 > unrolled thread

Save/restore breakpoints between pdb runs

Back to article view | Back to comp.lang.python

Contents

  Save/restore breakpoints between pdb runs Ed Blackman <ed@edgewood.to> - 2014-07-11 15:16 -0400
    Re: Save/restore breakpoints between pdb runs dieter <dieter@handshake.de> - 2014-07-12 08:05 +0200

#74362 — Save/restore breakpoints between pdb runs

I've recently started using Python for my job (as opposed to writing 
smallish scripts for personal use), and so have needed to debug quite a 
bit more.

I've been using pdb mainly via 'python -m pdb script args'.  Perhaps 
it's my Java background, but even when I have permissions to change the 
source, I find editing source to insert 'import pdb; pdb.set_trace()' 
unnatural.  The consequence is that I have to recreate my breakpoints 
when I have to exit pdb.

I've written the following code, which I load from .pdbrc with 
'execfile(os.path.expanduser('~/.pydb.py'))'

Is there an alternate solution to keeping persistant breakpoints that 
works much better?  My python editing happens on a lot of different 
machines/VMs, so I prefer alternate solutions that allow me to sync over 
a couple of files, not install new binaries.

If not:
1) If is there a way in pdb to set a breakpoint on a function that isn't 
in the current file?  I can see the .funcname property of the 
breakpoint, and would prefer restoring breakpoints on functions so they 
don't break if I change line numbers.  "b func_name" works in the 
current file, but "b file:func_name" doesn't.
2) Is there a way to list the commands for each breakpoint, so that they 
can be restored as well?

Any other comments or suggestions for improvement would be welcome.

def savebps():
    import pdb

    bp_num = 0
    for bp in pdb.bdb.Breakpoint.bpbynumber:
        # pdb commands operate on breakpoint number, so keep track of
        # the number the recreated breakpoint would have
        if bp is None:
            continue
        else:
            bp_num += 1

        command = 'tbreak' if bp.temporary else 'b'
        cond = '' if bp.cond is None else ', ' + bp.cond

        print("%s %s:%d%s" % (command, bp.file, bp.line, cond))

        if not bp.enabled:
            print("disable %d" % (bp_num))

        if bp.ignore > 0:
            print("ignore %d %d" % (bp_num, bp.ignore))

        print('')

-- 
Ed Blackman

[toc] | [next] | [standalone]

#74368

Ed Blackman <ed@edgewood.to> writes:
> I've recently started using Python for my job (as opposed to writing
> smallish scripts for personal use), and so have needed to debug quite
> a bit more.
>
> I've been using pdb mainly via 'python -m pdb script args'.  Perhaps
> it's my Java background, but even when I have permissions to change
> the source, I find editing source to insert 'import pdb;
> pdb.set_trace()' unnatural.  The consequence is that I have to
> recreate my breakpoints when I have to exit pdb.
>
> I've written the following code, which I load from .pdbrc with
> 'execfile(os.path.expanduser('~/.pydb.py'))'

This approach does not seem very robust to me:

  "pdb" resolves all breakpoints to lines (in source files) - and
  any modification to the source may change the lines.
  As a consequence, your breakpoints may no longer be at the
  places where you expect them.


A long time ago, I have developped "dm.pdb" - a slight
extension/improvement over "pdb". One of the extensions
has been to make it possible to set breakpoints from outside
the debugger -- without too many surprises. It looks somehow like that:

  from dm.pdb import Pdb; D = Pdb()
  ...
  from ... import f
  from ... import g
  from ... import C
  ...
  D.do_break("f") # set breakpoint on "f"
  D.do_break("g") # set breakpoint on "g"
  D.do_breack("C.m") # set breakpoint on method "m" of class "C"
  ...
  D.run("...")

It is more robust than breakpoints on line numbers - but, of course,
it cannot be automated but must be targeted to individual programs.
In addition, the robustness is limited to breakpoints on
executable objects; setting breakpoints on line numbers is possible, too --
but has the same problem with moving lines.


In the meantime, "pdb" itself may support this form of external
control (maybe even better then "dm.pdb").

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web