Skip to content

TraceRefs build triggers assertion errors #107630

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
Yhg1s opened this issue Aug 4, 2023 · 4 comments
Closed

TraceRefs build triggers assertion errors #107630

Yhg1s opened this issue Aug 4, 2023 · 4 comments
Assignees
Labels
release-blocker type-bug An unexpected behavior, bug, or error

Comments

@Yhg1s
Copy link
Member

Yhg1s commented Aug 4, 2023

In a --with-trace-refs --with-pydebug build of 3.12 and main, even a simple test like test_int triggers an assertion error in the refchain handling. I expect it's caused by @ericsnowcurrently's PR #107567.

cpython-tracerefs % ../../cpython/configure -C --with-trace-refs --with-pydebug
[...]
cpython-tracerefs % make
[...]
cpython-tracerefs % ./python -m test test_int
0:00:00 load avg: 2.79 Run tests sequentially
0:00:00 load avg: 2.79 [1/1] test_int

== Tests result: SUCCESS ==

1 test OK.

Total duration: 477 ms
Tests result: SUCCESS
../../cpython/Objects/object.c:2234: _Py_ForgetReference: Assertion failed: invalid object chain
Enable tracemalloc to get the memory block allocation traceback

object address  : 0x7ff86d998050
object refcount : 0
object type     : 0x55fbc49aba60
object type name: dict
object repr     : <refcnt 0 at 0x7ff86d998050>

Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: finalizing (tstate=0x000055fbc4b27e88)

Current thread 0x00007ff86daec740 (most recent call first):
  <no Python frame>
Aborted

Linked PRs

@Yhg1s
Copy link
Member Author

Yhg1s commented Aug 4, 2023

FWIW, if the fix for this is too involved or too complicated, I'd rather roll back #107567 and leave tracerefs broken when using isolated subinterpreters than leaving tracerefs broken for everything.

@ericsnowcurrently
Copy link
Member

I'm okay with a revert on 3.12. You're right that the previous state of affairs was better.

FWIW, there's an object leaking between interpreters somewhere and tracking that down is a big pain. I don't know how long it will take, so reverting now makes sense. I would like to un-revert once I've tracked down the culprit though.

Yhg1s pushed a commit that referenced this issue Aug 5, 2023
… Under Isolated Subinterpreters (gh-107567) (#107599)" (#107648)

Revert "[3.12] gh-107080: Fix Py_TRACE_REFS Crashes Under Isolated Subinterpreters (gh-107567) (#107599)"

This reverts commit 58af229.
@sunmy2019
Copy link
Member

Confirmed it is fixed on the 3.12 branch. The issue would remain open for the main branch.

ericsnowcurrently added a commit that referenced this issue Aug 7, 2023
This finishes fixing the crashes in Py_TRACE_REFS builds.  We missed this part in gh-107567.
ericsnowcurrently added a commit that referenced this issue Aug 7, 2023
…lds (gh-107750)

This is a follow-up to gh-107567 and gh-107733.

We skip test_basic_multiple_interpreters_deleted_no_reset on tracerefs builds.  The test breaks interpreter isolation a little, which doesn't work well with Py_TRACE_REFS builds, so I feel fine about skipping the test.
@ericsnowcurrently
Copy link
Member

Once gh-107751 lands, this can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-blocker type-bug An unexpected behavior, bug, or error
Projects
Development

No branches or pull requests

4 participants