gdb threadname() causing debugging problems

With the nightly snapshots for 3.0.0-rc1, I'm having problems when I stop at a breakpoint: the stacktrace is incorrect (showing other functions on top of the stack that are not related), I don't get any locals, and the state actually looks like the program is still running. Also, when I try to stop debugging, clicking stop isn't enough; I then need click the stop button on the applicaiton execution window to finally kill the application. I've attached screenshots for both good and bad, as well as the debugger log for good and bad.

By dropping the gdbbridge.py file into 3.0.0-beta (which works otherwise), I am able to reproduce the problem. I've isolated the commit that breaks this to a84963e, specifically line 1792 in gdbbridge.py. In this commit, the threadname() method looks up a type using self rather than object d, which is actually undefined. This appears to be a bug, which was introduced in commit 068a2909. This commit moved threadname() to a method and removed the creation of the d Dumper instance, but did not update the call to lookupType() to use self rather than d.

At any rate, I can fix the problem in the -rc1 nightly by replacing the self.lookupType() to instead create a new Dumper instance and use this to call lookupType(). Alternatively, I can break 3.0.0-beta by modifying gdbbridge to use self.lookupType(), so clearly this line is the problem. However, I have no idea why calling lookupType() while getting threadnames is problematic, so I'll leave that to someone smarter than me to figure out.