gh-117657: Enable TSAN check on macOS with free-threads build

[aisk]

There are some macOS only races, for example #120500, so I think maybe we should enable the test for macOS on GHA.

Another thing is that two TSAN tests will hang: #120696, so we should skip them with TSAN on macOS.

• Issue: Make TSAN tests pass with the GIL disabled in free-threaded builds #117657

[hugovk]

To avoid queuing up too many jobs for the limited number of macOS builders, we'd want to use macos-14 for forks, but Cirrus for upstream builds.

See elsewhere in this file for examples, also needs changes in the reusable workflow.

[colesbury]

I'm ambivalent about adding another TSan job. I'm not sure it's currently worth the extra CI resources and #120500 doesn't really seem like it uncovered a new race -- it might be due to the different version of clang or just a slightly different call stack that wasn't covered by the suppressions file.

[colesbury]

If this is hanging in faulthandler, that probably means the test is crashing.

[colesbury]

Faulthandler hanging is definitely not great, but even if faulthandler is fixed I expect there will still be a problem with this test.

[aisk]

These tests are just test the mallocator without the GIL, and intented to be crashed, so I think they are ok for now?

[colesbury]

Oh, that makes sense -- I missed that.

[aisk]

I'm ambivalent about adding another TSan job. I'm not sure it's currently worth the extra CI resources and #120500 doesn't really seem like it uncovered a new race -- it might be due to the different version of clang or just a slightly different call stack that wasn't covered by the suppressions file.

I have another idea. We can just modified the code to temporarily skip these two problematic tests and run the TSAN checks on macOS locally. What do you think?

[colesbury]

Yeah, I think we should be able to successfully run TSan tests locally on macOS.

There still seems to be some underlying bugs that we should fix. As you pointed out above, the test (in a subprocess) is supposed to crash because it calls PyMem_Malloc without holding the GIL / not having a valid thread state (the equivalent in the free-threaded build). The test runs:

PYTHONMALLOC=debug ./python -c "import _testcapi; _testcapi.pymem_malloc_without_gil()"

(I found it easier to run that directly under gdb or lldb than running the test case)

• On Linux in the free-threaded build, the faulthandler itself crashes in _Py_DumpExtensionModules because it's calling PyDict_Next without a valid thread state. The test still passes because it's already printed out some of the error message.
• On macOS, the faulthandler crash leads to a hang. I'm not sure why. I thought it might be re-entrantly triggering the faulthandler, but it doesn't look like that.

[aisk]

Hi @colesbury, I opened #120900 just to skip these two tests on macOS.