GeezerVison

only failing for Ubuntu (free-threading) / build and test (ubuntu-24.04-arm) and I cannot reproduce on my ubuntu arm VM

Edit: actually I did reproduce it after a couple attempts

@ebonnal thanks for the test! Your first test was good, and it found a bug https://github.com/python/cpython/actions/runs/14048391667/job/39333996238?pr=131701#step:22:632

I've pushed a commit to revert to the original style of test - which includes the references in the error message, and fixed the bug.

I've pushed a commit to revert to the original style of test - which includes the references in the error message, and fixed the bug.

Thanks @graingert !

probably we also need to finally: del exc_wrapper here too

Nice, I have cleaned up this exc_wrapper and added an additional test that goes through the error's traceback frames and search for any reference to an Exception.

(I have renamed the PR to show that we have extended its scope)

@graingert via my recent cosmetic changes I have noticed that the get_referrers test fails from time to time in a non deterministic way (e.g. https://github.com/python/cpython/actions/runs/14169734692/job/39690706469?pr=131701#step:22:777):

• build: it only concerns the free-threading builds (configured with --disable-gil)
• test: the failing module is either test_interpreter_pool or test_process_pool
• platform: only on Ubuntu or Windows, the test never fails on macos. (I confirm that I have successfully reproduced the issue multiple times on an Ubuntu VM, and never on my local macos).

-> as a deterministic workaround in those situations, I have added an explicit gc collection before the test:

if (
    '--disable-gil' in get_config_var("CONFIG_ARGS")
    and sys.platform in ("linux", "win32")
):
    gc.collect()

I wonder if this GC issue with free-threading builds is a known issue. I also wonder if we should investigate this further as part of this PR or if we should open an issue 🤔 Let me know your thoughts!

When debugging these sorts of things I usually use a mix of the packages objgraph and refcycle. Can you repeat this locally? I'll see if I can find out what's going on

ok I can't repeat it locally, even disabling the GC - sorry for hijacking your PR but I think I need to test it in CI to repeat

Hey @graingert, update from my investigations with a free-threading build on an Ubuntu ARM machine:
It fails like 50% of the time, looking like some GC race condition, but the test is always successful if we pause for a bit with a time.sleep(1) before checking the referrers.
Maybe for the scope of this PR we should go back to the state of 03f8ab4 and just add this little pause?

I don't think it's a gc race condition as the problem still happens with the GC disabled. I think the problem is that the main thread is resumed before the background thread can delete the future.

I'm happy for you to revert back to 03f8ab4