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.

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.

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

>>> len(inspect.findsource(_frozen_importlib)[0])
1761
>>> len(inspect.findsource(importlib._bootstrap)[0])
1761

Which are accurate line counts::

$ wc Lib/importlib/_bootstrap.py 
 1761  6236 62517 Lib/importlib/_bootstrap.py

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

This should mostly be resolved in 3.10. See issue gh-65935 (and PR gh-28656).