Issue 17971: Weird interaction between Komodo Python debugger C module & Python 3 (original) (raw)

While much of Komodo's source code has been released under MIT/GPL/LGPL, the Python debugger hasn't, so I can't post it here. We can work out an arrangement later, although it might not be necessary once I describe the problem:

Komodo's Python debugger was a pure-Python debugger, based on pdb. To make it possible to debug the Chandler app, one of the components was written in C against the CPython API, for performance, and all was good.

With Python 3, breakpoints no longer work after an exec with an explicit globals arg, where globals is a user-supplied dict, not "globals()" or "locals()". For example, in this code:

print("I'm line 1") namespace = {} exec("a = 42", namespace) print("I'm line 4") print("Done")

Set breakpoints at lines 1 and 4. Start the debugger in "Run" mode (stops at first breakpoint). The debugger stops at line 1. Press continue. The debugger runs to end, without stopping.

If the namespace arg to exec is deleted, or replaced with "globals()" or "locals()", (quotes are typographic, not literal), the breakpoint at line 4 is honored. It only fails when globals is set to a new dict.

Additionally, if the namespace is defined like so: namespace = {"DBGPHide": 1}, the breakpoint is honored. The debugger marks its internal frames with directives like "DBGPHide" to avoid stepping into them. Yes, it's a hack.

Adding more diagnostics to the C file shows that the first time the debugger finds a frame with a global named DBGPHide, name is "dbgp.common". This makes sense, because that module sets DBGPHide to 1, but after every other time, name is "main" , and DBGPHide isn't set on it.

I had a look at the implementation of exec in Python 3.3 in bltinmodule.c and ceval.c, but don't see anything obvious.

Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98951

I found a workaround in our debugger code, so you can lower the priority on this, or even mark it "Wontfix", although I still think the frame stack is getting messed up.

One thing about our debugger, it essentially runs all the Python code in a big exec statement, and this particular code contains its own exec stmt. The stack looks wrong after we finish the inner exec statement. So if you're looking for a repro, that might be the way to go. However I can break at line 10 in the following code with no problem using pdb (Py 3):

 1  #!/usr/bin/env python3
 2
 3  def inner_f(a, b):
 4      ns2 = {"c": 7, "a":a, "b":b, "tot":None }
 5      exec("tot = a + b + 1 + 100 * c", ns2)
 6      return ns2['tot']
 7
 8  ns1 = {"c": 5, "inner_f": inner_f, "res":None }
 9  exec("res = inner_f(3, 4) + 10 * c", ns1)
10  print("After all that, res: %d" % (ns1['res'],))
11  print("Stop here")