gh-130052: Fix some exceptions on error paths in _testexternalinspection#130053
Conversation
|
cpython/Modules/_testexternalinspection.c Line 917 in 67072cc Refcnt doesn't used - maybe we may remove this reading? cpython/Modules/_testexternalinspection.c Line 1529 in 67072cc This is a typo - should I fix them? get_stack_trace should be get_async_stack_trace
|
|
@pablogsal Please take a look. I saw your fixed some calls (#129557), I added a few more exceptions. I also added a check of the result before it is used. |
|
@sergey-miryanov: Why did you mark this PR as a draft? Do you expect to add more changes? Or is there something else? |
|
@vstinner oops! I forgot to un-draft it. Thanks! |
Modules/_testexternalinspection.c
Outdated
| if (proc_ref == 0) { | ||
| PyErr_SetString(PyExc_PermissionError, "Cannot get task for PID"); | ||
| if (!PyErr_Occurred()) { | ||
| PyErr_SetString(PyExc_PermissionError, "Cannot get task for PID"); |
There was a problem hiding this comment.
Would it be posssible to move this code inside pid_to_task()? I'm not convinced that PermissionError is appropriate, I would suggest RuntimeError instead.
There was a problem hiding this comment.
I believe it is redundant here. I will remove this check. But I saw on the internets that task_for_pid may return code == 5 (os/kern failure) that we don't check - should we?
There was a problem hiding this comment.
Oh! I think PyExc_PermissionError is just exactly for this. I will move it to pid_to_task.
There was a problem hiding this comment.
I kept PyExc_PermissionError and removed redundant check. Should I replace PermissionError with RuntimeError?
Co-authored-by: Victor Stinner <vstinner@python.org>
|
@vstinner Please take a look. |
|
Thanks @sergey-miryanov for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13. |
|
Sorry, @sergey-miryanov and @vstinner, I could not cleanly backport this to |
|
@vstinner It looks like a lot of changes were made on 3.14 branch and not on 3.13. Should we backport this PR then? |
|
The automated backport failed because of merge conflicts. @sergey-miryanov: Can you please try to backport this change manually to 3.13? |
|
@vstinner I tried yesterday yet. There are commits that not backported: Should I backport them all? |
|
@pablogsal: |
3.13 has half the test cases because there is no async-related introspection and most of the bugs we have been fixing are in the new code. I will try to go over the PRs and see if anything applies to the other code that we had |
|
Reminder about backporting. @sergey-miryanov |
|
I'm afraid it is on @pablogsal side now. I'm not against of backporting those commits and if we decide to do this I'm ready to work on backporting. |
|
If it was decided to not backport this, please remove the "needs backport to 3.13" label. |
|
It is on @pablogsal side to take decision of backporting this. I will remove "need backport@ label for now. |
Some error paths don't set Exceptions.
This PR fixes them.