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