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

Since this seems to be some sort of interaction between Komodo's code and Python (it works for me with vanilla Python 3), it's going to be hard to debug without seeing what this other thing is doing.

I'm running it inside gdb to see if I can figure it out.

I don't see a way of isolating this from the whole product.

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")

If you ever find a Python bug, feel free to reopen.