Skip to content

bpo-44461: Fix bug with pdb's handling of import error due to a packa… #26937

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

iritkatriel
Copy link
Member

@iritkatriel iritkatriel commented Jun 28, 2021

…ge which does not have a main module

https://bugs.python.org/issue44461

@iritkatriel iritkatriel requested a review from jaraco June 28, 2021 16:14
@iritkatriel iritkatriel added needs backport to 3.9 only security fixes needs backport to 3.10 only security fixes type-bug An unexpected behavior, bug, or error awaiting core review labels Jun 28, 2021
Copy link
Member

@jaraco jaraco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really appreciate the PR here and your analysis in the bug. Nice work.

One thing I notice is that .runmodule and .runscript are symmetric operations, and one of the reasons that .reset() isn't invoked is because in .runmodule, the viability of the target (-m package.mod) isn't checked until in the runmodule step, whereas in the file-based approach, the presence of the file is checked early and SyntaxErrors are trapped separately.

Perhaps runmodule should do something similar and handle non-existence of an executable module (here) by raising a distinct exception to be handled separately in the main loop. Then, the conditions that lead to .botframe not being set would never get triggered (similar to how things are handled when a script is missing or has a SyntaxError).

WDYT?

Comment on lines +1731 to +1732
if pdb._user_requested_quit:
break
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After experimenting, I understand the motivation for this change here, but I also worry that it might affect other workflows we haven't considered. Could there be other use-cases where a different Exception occurred and pdb._user_requested_quit is True, but we would want that to fall through (not break)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. self._user_requested_quit will be True only when we get quit()/exit() or EOF. ISTM that it's safe to exit in both cases.

I'm pretty sure I've had to kill pdb processes in the past, when they stopped responding to quit(), so I would guess it's more likely that there are other code paths that would benefit from this change.

Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>
@iritkatriel
Copy link
Member Author

Closing as this is no longer under consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting core review needs backport to 3.9 only security fixes needs backport to 3.10 only security fixes type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants