Skip to content

gh-135106: [crash repro] Randomly deposit objects in _Py_Dealloc #135589

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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

colesbury
Copy link
Contributor

@colesbury colesbury commented Jun 16, 2025

Returns 1 a little less than 1% of the time in
_Py_RecursionLimit_GetMargin() to force the use of the trashcan mechanism.

This isn't intended to be merged. It's just to:

  1. Demonstrate the crash
  2. Test on a variety of platforms and configs from the CI

Returns `1` a little less than 1% of the time in
_Py_RecursionLimit_GetMargin() to force the use of the trashcan
mechanism.
@colesbury colesbury changed the title gh-135106: Randomly return 1 in _Py_RecursionLimit_GetMargin gh-135106: [crash repro] Randomly return 1 in _Py_RecursionLimit_GetMargin Jun 16, 2025
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
@markshannon
Copy link
Member

I don't think this shows anything more than that randomly changing the stack limit causes crashes.

The trashcan mechanism relies on the margin being larger for frames higher up the call stack. This breaks that invariant.

You could try changing margin > 2 and margin >= 4 to much larger numbers to see if that provokes a failure.

@hugovk hugovk force-pushed the gh-135106-crash-demo branch from f0ef510 to 92e82ac Compare June 17, 2025 07:32
@hugovk

This comment was marked as resolved.

@colesbury colesbury changed the title gh-135106: [crash repro] Randomly return 1 in _Py_RecursionLimit_GetMargin gh-135106: [crash repro] Randomly deposit objects in _Py_Dealloc Jun 17, 2025
@colesbury colesbury force-pushed the gh-135106-crash-demo branch from da82cbb to 7c86a25 Compare June 17, 2025 17:08
@colesbury
Copy link
Contributor Author

I don't think this shows anything more than that randomly changing the stack limit causes crashes.

The only thing that matters here is the condition to deposit objects -- there's no invariant to be broken. I've updated the test to make that more clear. It should always be safe to deposit an object conservatively (i.e., to treat the available stack as smaller).

Here's the equivalent test with the old trashcan behavior, which works without crashing:
https://github.com/colesbury/cpython/tree/gh-135106-test-old-behavior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants