The mimalloc 2.5.2 update (gh-159111) dropped the CPython-specific check from gh-123022 in Objects/mimalloc/os.c, which skips _mi_heap_random_next() while the thread's default heap is not initialized. It looks like another downstream change lost in the upgrade, like the ones restored in gh-160207. This restores it as it was before the update.

On 3.14 the missing check makes Py_Initialize() in a background thread crash on free-threaded release builds (test_init_in_background_thread fails). On main the test passes even without the check, because the raw domain already initializes the heap; the change is here so that it can be backported to 3.15 and 3.14. If gh-159718 (mimalloc v3) lands first, this is not needed on main and could go to 3.15 and 3.14 directly.

Tested on macOS with free-threaded release builds: with this change the test passes 20 of 20 times on 3.14 (20 of 20 crashes without it), and test_embed passes on main and 3.14.

No NEWS entry: the regression is not in any release yet (3.14.9 still has the check).

See #160588.

• Issue: Py_Initialize() in a background thread crashes on free-threaded release builds of 3.14 after the mimalloc 2.5.2 update #160588