Skip to content
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

Signal handlers don't skip incomplete frames #96754

Closed
kumaraditya303 opened this issue Sep 11, 2022 · 6 comments
Closed

Signal handlers don't skip incomplete frames #96754

kumaraditya303 opened this issue Sep 11, 2022 · 6 comments
Assignees
Labels
3.11 only security fixes 3.12 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@kumaraditya303
Copy link
Contributor

Currently signal handlers don't skip incomplete frames and this leads to crash when creating frame object. Incomplete frames should be skipped in _PyErr_CheckSignalsTstate.

@kumaraditya303 kumaraditya303 added type-bug An unexpected behavior, bug, or error interpreter-core (Objects, Python, Grammar, and Parser dirs) 3.11 only security fixes type-crash A hard crash of the interpreter, possibly with a core dump 3.12 bugs and security fixes labels Sep 11, 2022
@mdboom
Copy link
Contributor

mdboom commented Sep 11, 2022

To make sure we aren't playing "whac-a-mole", is there a way to find all of these cases and/or improve the internal API?

@kumaraditya303
Copy link
Contributor Author

It depends upon if the function calls back into python with a frame reference. I don't think these can be found all at once, it requires following the entire call chain and if the callback can be overridden.

@mdboom
Copy link
Contributor

mdboom commented Sep 12, 2022

Ok, thanks for the clarification, @kumaraditya303.

@markshannon
Copy link
Member

This looks possible, but extremely unlikely, as AFAICT it can only happen in a C extension called during GC or from a finalizer, which then calls Py_MakePendingCalls

There may be other cases, but I suspect they are just as obscure.
We should fix this, and backport it. But I don't think we need worry about it too much.

@mdboom Looking through the code, there are two other places we don't check whether the frame is valid.
There aren't that many calls to _PyFrame_GetFrameObject so it easy to check them all.

@pablogsal Want the fix in 3.11.0 or is 3.11.1 OK?

@pablogsal
Copy link
Member

3.11.1 unless you think it absolutely needs to go on 3.11.0

@kumaraditya303
Copy link
Contributor Author

To be clear I was only able to reproduce this once, so yeah extremely unlikely but can be hit in pure python but I have no small reproducer.

miss-islington pushed a commit to miss-islington/cpython that referenced this issue Sep 13, 2022
…e creating frame object. (pythonGH-96776)

(cherry picked from commit 12c5f32)

Co-authored-by: Mark Shannon <mark@hotpy.org>
pablogsal pushed a commit that referenced this issue Sep 13, 2022
…ting frame object. (GH-96776) (#96787)

(cherry picked from commit 12c5f32)

Co-authored-by: Mark Shannon <mark@hotpy.org>

Co-authored-by: Mark Shannon <mark@hotpy.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.11 only security fixes 3.12 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

4 participants