Repository navigation
Crash During Subinterpreter Finalization #105699
Description
Activity
Probably the same thing:
(AMD64 Arch Linux TraceRefs 3.12)
test_one (test.test__xxsubinterpreters.DestroyTests.test_one) ... ok Objects/object.c:2211: _Py_ForgetReference: Assertion failed: invalid object chain Enable tracemalloc to get the memory block allocation traceback object address : 0x7f6bf962d300 object refcount : 0 object type : 0x55a320cd18c0 object type name: bytes object repr : <refcnt 0 at 0x7f6bf962d300> Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed Python runtime state: initialized Current thread 0x00007f6c09e2e740 (most recent call first): <no Python frame> Debug memory block at address p=0x7f6c09d55e90: API '�' 18302063728033398269 bytes originally requested The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfd): at p-7: 0xdd *** OUCH at p-6: 0xdd *** OUCH at p-5: 0xdd *** OUCH at p-4: 0xdd *** OUCH at p-3: 0xdd *** OUCH at p-2: 0xdd *** OUCH at p-1: 0xdd *** OUCH Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 8 pad bytes at tail=0xfdfe7d6a07d35c8d are Fatal Python error: Segmentation fault Current thread 0x00007f6c09e2e740 (most recent call first): <no Python frame> Extension modules: _testcapi, _xxsubinterpreters, _xxinterpchannels (total: 3) make: *** [Makefile:2015: buildbottest] Segmentation fault (core dumped)maybe related: #105690
After gh-106899, I'm
onlyseeing 3 very infrequent crashers:- failing assertion in _xxinterpreterchannelsmodule.c (not user-facing)
- bogus interned string state
- something bad in start_thread() (pthread)
(stack track for that last one)
Thread 1 (Thread 0x7f1c41efb700 (LWP 27875)): #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f1c4a6bd7f1 in __GI_abort () at abort.c:79 #2 0x00007f1c4a706837 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f1c4a833a7b "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x00007f1c4a70d8ba in malloc_printerr (str=str@entry=0x7f1c4a831c8e "free(): invalid size") at malloc.c:5342 #4 0x00007f1c4a818a6c in _int_free (have_lock=0, p=0x7f1c28001490, av=0x7f1c28000020) at malloc.c:4171 #5 __GI___libc_free (mem=0x7f1c280014a0) at malloc.c:3134 #6 tcache_thread_shutdown () at malloc.c:2979 #7 arena_thread_freeres () at arena.c:950 #8 0x00007f1c4a819562 in __libc_thread_freeres () at thread-freeres.c:29 #9 0x00007f1c4b21a700 in start_thread (arg=0x7f1c41efb700) at pthread_create.c:476 #10 0x00007f1c4a79e61f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95With the 3 PRs I have up I don't see any more crashes (other than in _xxinterpchannels).
13 remaining items
- added 4 commits that reference this issue
on Jul 27, 2023 I've disable the new stress tests as they were causing crashes regularly that I'm not convinced indicate bugs (outside _xxsubinterpreters). Once that's sorted out and I've re-enabled the tests, we can close this issue.
I'm calling this good.
- added 4 commits that reference this issue
on Nov 27, 2023
Metadata
Metadata
Assignees
Labels
Projects
- Status
There's an isolation leak somewhere. It may be just in the _xxsubinterpreters module, but I suspect it's not.
See #99114 (comment).
Reproducers:
FYI, I see crashes on this fairly infrequently.
Linked PRs