Repository navigation
can't step through _frozen_importlib/importlib._bootstrap using pdb #60115
Description
| BPO | 15911 |
|---|---|
| Nosy | @brettcannon, @ericsnowcurrently |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2012-09-10.19:30:36.307>
labels = ['interpreter-core', 'type-bug', 'library', '3.9']
title = "can't step through _frozen_importlib/importlib._bootstrap using pdb"
updated_at = <Date 2020-01-29.00:42:31.587>
user = 'https://bugs.python.org/exarkun'bugs.python.org fields:
activity = <Date 2020-01-29.00:42:31.587>
actor = 'brett.cannon'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core', 'Library (Lib)']
creation = <Date 2012-09-10.19:30:36.307>
creator = 'exarkun'
dependencies = []
files = []
hgrepos = []
issue_num = 15911
keywords = []
message_count = 3.0
messages = ['170221', '170224', '170301']
nosy_count = 4.0
nosy_names = ['brett.cannon', 'exarkun', 'Arfrever', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15911'
versions = ['Python 3.9']
Activity
exarkun commentedon Sep 10, 2012
Debugging problems involving the frozen importlib._bootstrap is difficult, because the source for importlib._bootstrap is not available to pdb. The bootstrap code can be stepped through, but with only function names and line numbers available, not source lines.
The value of having importlib written in Python would be greatly enhanced if it were more like a regular Python module that, eg, pdb could display source lines from.
ericsnowcurrently commentedon Sep 10, 2012
This comes back to bpo-14657, which addressed the frozen vs. non-frozen copies of importlib. It sounds like one useful solution for your situation would be for _frozen_importlib to be used only long enough for bootstrap purposes. This was discussed in that other issue.
brettcannon commentedon Sep 11, 2012
I'm going to guess this is a shortcoming of pdb when it comes to frozen modules as I can get to the source using inspect (which pdb leans on)::
Which are accurate line counts::
So why gdb can't output the source line when it has the line number of the file I don't know when it can already get access to the source without issue.
And yes, debugging imports are hard. =) Still, it's better than before as you can easily toss in a print statement or two and then just regenerate the frozen object. But I do agree it would be nice to get gdb to play along with the whole situation (and thus the title change for this bug).
[-]Debugging import problems is hard[/-][+]can't step through _frozen_importlib/importlib._bootstrap using gdb[/+][-]can't step through _frozen_importlib/importlib._bootstrap using gdb[/-][+]can't step through _frozen_importlib/importlib._bootstrap using pdb[/+]ericsnowcurrently commentedon Jul 21, 2022
This should mostly be resolved in 3.10. See issue gh-65935 (and PR gh-28656).
gsnedders commentedon Jan 23, 2025
For those like me who stumble across this, on 3.13:
So while it isn't actually printing the current line during execution,
listdoes manage to get the source.gh-60115: Support frozen modules for linecache.getline() (#131638)