running set_trace() multiple times displays stdlib bdb.py about pudb HOT 20 CLOSED

This seems to only happen with a breakpoint defined.
I also note that any defined breakpoints become doubled when the bug happens.
This often leads to an enormous breakpoint list after a while.

from pudb.

Can't reproduce this with Python 2.7, Urwid 1.0.1, Pudb from git.

from pudb.

Ah, only just saw your comment on breakpoints. I've reproduced this and will look into it.

from pudb.

FYI--I'm currently applying for jobs and don't have a ton of time, so if you've got time to look into this and send a patch, I'd much appreciate it. (Same goes for the other bug.)

from pudb.

I've fixed the breakpoint doubling in git. That was a silly, unrelated thing.

from pudb.

I don't think this has anything to do with having saved breakpoints.

from pudb.

@asmeurer Correct. You don't need saved breakpoints to reproduce this. Just debug with pudb and try to step (or continue) past a set_trace, and you'll be dropped into bdb.py.

It seems to me that there must be something that blacklists pudb code as being "not part of the code", but it neglected to include working for these few lines of bdb.py.

Incidentally, this hypothetical blacklisting functionality makes it hard / impossible to debug pudb using pudb.

from pudb.

As noted at #63, this also happens with the new Ctrl-c behavior if you break in the middle of an atomic operation (like time.sleep(10)).

Regarding debugging PuDB with PuDB, yeah, there probably aren't very many debuggers that can debug themselves. Quis custodiet ipsos custodes? and all that. The real issue in my experience is just the fact that it runs a terminal GUI. Also, it eats up stdout (or at least hides it), so print statements are worthless. If you find yourself needing to debug PuDB, see http://lists.tiker.net/pipermail/pudb/2011-August/000039.html.

from pudb.

@inducer seems to indicate the meta-debugging issue is the fault of bdb.py
I wonder if this means this issue (#52) is also the fault of bdb.py

If we can make a minimal case reproducing this behavior with just bdb.py, we should be able to make a case for a patch.

from pudb.

It does have something to do with breakpoints. Without any breakpoints, this issue does not occur. That said, it's not likely to be bdb's fault, since pdb doesn't have this issue.

from pudb.

I deleted my breakpoints file and this still happens.

from pudb.

As in, you had no breakpoints at all set, did not set any new ones, and you still ended up in bdb? That's not what I'm seeing. Without breakpoints, everything is fine for me.

from pudb.

Yes. I even completely removed .config/pudb and ran with the default settings, and as soon as I press n on set_trace() it goes to bdb. This is in every Python version that I have managed to get urwid installed in.

from pudb.

As in, from a completely clean slate, you run

python foobar.py foo bar

then hit n, and bam, you're in bdb?

from pudb.

It's a few ns with foobar, but yes. The example I was using was pudb test.py, where test.py is

from pudb import set_trace
set_trace()

which I guess is technically a different code path (but it doesn't matter in this case; starting PuDB from set_trace or from pudb.run both go to bdb if set_trace is hit while debugging).

from pudb.

This script reproduces the issue. I noticed you have to press n rather than c.

import pudb 
pudb.set_trace()
pudb.set_trace()

from pudb.

This patch works around the issue. Apparently there's some leftover state in the cached Debugger that is causing this behavior.

diff --git a/pudb/__init__.py b/pudb/__init__.py
index 02349eb..cea9fe0 100644
--- a/pudb/__init__.py
+++ b/pudb/__init__.py
@@ -115,7 +115,8 @@ def runcall(*args, **kwds):

 def set_trace():
     import sys
-    dbg = _get_debugger()
+    from pudb.debugger import Debugger
+    dbg = Debugger() #_get_debugger()

     set_interrupt_handler()
     dbg.set_trace(sys._getframe().f_back)

from pudb.

I can reproduce the issue in pdb with this:

from pdb import Pdb
debugger = Pdb()
debugger.set_trace()
debugger.set_trace()

from pudb.

patching stdlib bdb.py in this way fixes the issue (and stdlib unit tests continue to pass).

You might put this into pudb as a method override for now, and see if anything untoward happens. If not, it's a fair argument for upstreaming.

diff -r ef8ea052bcc4 Lib/bdb.py
--- a/Lib/bdb.py        Sun Mar 17 22:06:18 2013 -0400
+++ b/Lib/bdb.py        Mon Mar 18 15:06:04 2013 -0700
@@ -212,15 +212,14 @@
     def set_trace(self, frame=None):
         """Start debugging from `frame`.

         If frame is not specified, debugging starts from caller's frame.
         """
         if frame is None:
             frame = sys._getframe().f_back
-        self.reset()
         while frame:
             frame.f_trace = self.trace_dispatch
             self.botframe = frame
             frame = frame.f_back
         self.set_step()
         sys.settrace(self.trace_dispatch)

from pudb.

#67 was merged.

from pudb.