This test case checks that freeing a code object on a different thread then where the co_extra was set is safe. However, the test make some assumptions about when destructors are called that aren't always true in the free-threaded build:

In particular, the assertion self.test.assertEqual(LAST_FREED, 500) in the ThreadTest occasionally fails because LAST_FREED is still None. The underlying issue is that biased reference counting can delay the calling of the code object's destructor.

Normally, the gc_collect() calls are sufficient to ensure that the code object is collected. They sort of are -- the code object is being freed -- but it happens concurrently in the main thread and may not be finished by the time ThreadTest calls the self.test.assertEqual(LAST_FREED, 500).

The timeline I've seen when debugging this is:

1. The main thread starts ThreadTest
2. ThreadTest deletes the final reference to f. The total reference count is now zero, but it's represented as ob_ref_local=1, ob_ref_shared=-1, so TestThread enqueues it to be merged by the main thread.
3. The main thread merges the reference count fields and starts to call the code object's destructor
4. ThreadTest calls gc_collect() and then self.test.assertEqual(LAST_FREED, 500), which fails
   ...
5. The main thread finishes calling the code object's destructor, which sets LAST_FREED to 500.

Linked PRs

• gh-117683: Fix test_free_different_thread failures with GIL disabled #117685