GeezerVison is showing github.com — Crash During Subinterpreter Finalization · Issue #105699 · python/cpython
Crash During Subinterpreter Finalization #105699DescriptionThere'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
Activityericsnowcurrently commented on Jun 12, 2023 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)
ericsnowcurrently commented on Jun 12, 2023 ericsnowcurrently commented on Jul 19, 2023 After gh-106899, I'm only seeing 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:95
ericsnowcurrently commented on Jul 20, 2023 With the 3 PRs I have up I don't see any more crashes (other than in _xxinterpchannels). ericsnowcurrently commented on Jul 31, 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. ericsnowcurrently commented on Aug 8, 2023
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|