Skip to content

[3.14] gh-137400: Fix a crash when disabling profiling across all threads (gh-137471) #137648

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Aug 12, 2025
Merged

[3.14] gh-137400: Fix a crash when disabling profiling across all threads (gh-137471) #137648

merged 1 commit into from
Aug 12, 2025
+46 −2

Conversation

miss-islington
Copy link
Contributor

@miss-islington miss-islington commented Aug 11, 2025 •
edited by bedevere-app bot
Loading

The PyEval_SetProfileAllThreads function and other related functions
had a race condition on tstate->c_profilefunc that could lead to a
crash when disable profiling or tracing on all threads while another
thread is starting to profile or trace a a call.

There are still potential crashes when threads exit concurrently with
profiling or tracing be enabled/disabled across all threads.
(cherry picked from commit 3626928)

Co-authored-by: Sam Gross colesbury@gmail.com

@colesbury @miss-islington
pythongh-137400: Fix a crash when disabling profiling across all thre…
77f9ca6 
…ads (pythongh-137471)

The `PyEval_SetProfileAllThreads` function and other related functions
had a race condition on `tstate->c_profilefunc` that could lead to a
crash when disable profiling or tracing on all threads while another
thread is starting to profile or trace a a call.

There are still potential crashes when threads exit concurrently with
profiling or tracing be enabled/disabled across all threads.
(cherry picked from commit 3626928)

Co-authored-by: Sam Gross <colesbury@gmail.com>
This was referenced Aug 11, 2025
Open
Merged
@colesbury
Copy link
Contributor

@hugovk

From @pablogsal's comment in #137400 (comment):

The worry we have is that this is going to segfault for a bunch of users, and we’ll burn a lot of effort trying to diagnose whether issues are caused by this bug or something else.

So it would be great to get it in 3.14.0 if possible, but we understand if that’s not possible or if you want to wait until the next release.

From our perspective, having users hit segfaults in production when using memray with Python 3.14.0 has the risk to create a significant support burden - we’d have to triage every crash report to determine if it’s this known issue or something new and given the nature of this problem that may be a pain to guide the user or even get a reproducer. Getting the fix into 3.14.0 would save both our users and ourselves from that pain.

That said, we appreciate the trade-offs involved here so if the bigger fix needs more time to bake, the smaller fix in 3.14.0 might be a reasonable compromise to at least prevent the segfaults, even if it doesn’t address all the thread-safety issues.​​​​​​​​​​​​​​​​

@hugovk
Copy link
Member

hugovk commented Aug 12, 2025

Let's go with this smaller fix for 3.14.0 RC2. Thanks!

@hugovk hugovk merged commit 4ebd928 into python:3.14 Aug 12, 2025
84 of 86 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@colesbury colesbury colesbury approved these changes

@kumaraditya303 kumaraditya303 kumaraditya303 approved these changes

Assignees

@hugovk hugovk

Labels
topic-free-threading
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@miss-islington @colesbury @hugovk @kumaraditya303