Segfault in GC at shutdown in 3.14-alpha.5

[bdarnell]

Bug report

Bug description:

While testing Tornado's test suite on 3.14-alpha.5, I found that after running certain (innocuous-looking) tests I would get a segfault in GC as the process shuts down. Unfortunately faulthandler doesn't give me any useful information:

(tornado) bdarnell@MacBookPro tornado % PYTHONFAULTHANDLER=1 uv run --no-project -p 3.14 python  -m tornado.test tornado.test.ioloop_test.TestPeriodicCallbackAsync.test_periodic_plain
.
----------------------------------------------------------------------
Ran 1 test in 0.031s

OK
Fatal Python error: Segmentation fault

Current thread 0x00000001f7ee4840 (most recent call first):
  Garbage-collecting
  <no Python frame>

I've narrowed the problem down to two tests in TestPeriodicCallbackAsync, test_periodic_plain and test_periodic_coro. Curiously, the very similar test_periodic_async test in the same class does not trigger the segfault. The GC failure appears to be deterministic when either of these tests are run and does not occur on any older version from 3.9-3.13. I've seen it on both macOS and linux (ubuntu 22.04 and 24.04).

The tests themselves are small, although they pull in a non-trivial amount of machinery from Tornado and asyncio (note that this is all pure python on the Tornado side; the small amount of C code we use isn't imported in this test). I'll see if I can reduce the test case further to be more self-contained. Is there anything that can be done to get more information about the objects being GC'd in the failure?

The exact tornado commit I'm testing is tornadoweb/tornado@5ae2fbb. This includes some unmerged changes to adapt to new deprecation warnings.

CPython versions tested on:

3.14

Operating systems tested on:

Linux, macOS

[colesbury]

Stacktrace is the following, which makes me think this is the same bug as:

• Crash when accessing the asyncio module state in task deallocation #130221 (cc @kumaraditya303)

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
  * frame #0: 0x00000001014b4c58 libpython3.14.dylib`PyType_GetModuleByDef + 60
    frame #1: 0x0000000101d00d54 libpython3.14.dylib`TaskObj_dealloc + 48
    frame #2: 0x00000001015e0c94 libpython3.14.dylib`set_dealloc + 260
    frame #3: 0x000000010136c554 libpython3.14.dylib`dictkeys_decref.llvm.13609225281458662827 + 116
    frame #4: 0x00000001015e6b18 libpython3.14.dylib`type_clear + 52
    frame #5: 0x0000000101476ccc libpython3.14.dylib`gc_collect_region + 2596
    frame #6: 0x0000000101475aa4 libpython3.14.dylib`_PyGC_Collect + 3944
    frame #7: 0x00000001014b9c34 libpython3.14.dylib`finalize_modules + 5528
    frame #8: 0x00000001014e1644 libpython3.14.dylib`_Py_Finalize.llvm.18389874993806621089 + 344
    frame #9: 0x00000001014e03b8 libpython3.14.dylib`Py_RunMain + 268
    frame #10: 0x00000001014aba88 libpython3.14.dylib`pymain_main + 468
    frame #11: 0x00000001014ab8a8 libpython3.14.dylib`Py_BytesMain + 40
    frame #12: 0x0000000190860274 dyld`start + 2840

[colesbury]

Yeah, I can reproduce the crash in 3.14.0a5, but not in main, so I think this was fixed yesterday.

[colesbury]

Thanks for the report and easy reproduction!

[bdarnell]

Great, thanks for the quick response!