gh-57537: Support breakpoints for zipimport modules on pdb #130290
Conversation
Lib/test/test_pdb.py
Outdated
| 'p x + x', | ||
| 'q' | ||
| ])) | ||
| self.assertIn('82', stdout) |
There was a problem hiding this comment.
It's the result of p x + x, I want to confirm that we did stop inside foo.bar. I can maybe change the testing code to use string so it's more obvious? Or I can add a comment here. The other possibility is to use a more advanced command to rule out the false positives (for example, you can't simply check bar because it will be shown anyway).
There was a problem hiding this comment.
Yes, a string would be better.
There was a problem hiding this comment.
I constructed a small piece of unique string and the assertion is close to the command - I think that made it clearer.
| @@ -1134,6 +1134,7 @@ def do_break(self, arg, temporary=False): | |||
| filename = None | |||
| lineno = None | |||
| cond = None | |||
| module_globals = None | |||
There was a problem hiding this comment.
I'd probably call this func_globals. Up to you.
There was a problem hiding this comment.
I was trying to match the name for linecache. It is a module globals acquired from a function, and the part matters is about the module (loader and stuff).
Currently when pdb sets a breakpoint on a known function, it uses the filename of the code object of that specific function to locate the source. However, this does not work for zipimport modules, because the
module_globalspassed in is of the current frame, andlinecacheneeds that to get the source.The correct way to deal with this is to pass in the
module_globalsof the function itself, not of the current frame. This not only solves the problem for zipimport, but also fixes other potential issues when the module of the function has its own loader.