gh-154431: Fix data race in sys.audithook

[sobolevn]

Test values are decreased, so this test can finish in a reasonable amount of time. It does not trigger in 100% of cases with TSAN enabled, but quite enought to notice its regressed failures in the future.

• Issue: Data race: sys.addaudithook() lazily creates interp->audit_hooks with no lock #154431

[miss-islington-app]

Thanks @sobolevn for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14, 3.15.
🐍🍒⛏🤖

[bedevere-app]

GH-154477 is a backport of this pull request to the 3.15 branch.

[bedevere-app]

GH-154478 is a backport of this pull request to the 3.14 branch.

[sobolevn]

Oh, @ambv looks like we can't really backport this. Because of the ABI change. What should we do? 🤔

[sobolevn]

Maybe we can reuse interp->runtime->audit_hooks.mutex?

[ZeroIntensity]

Apologies for not reviewing in time. I'm not so sure that a lock was the best choice here.

I think it would have been better to just initialize the list eagerly rather than lazily, which is simpler and solves the ABI problem. Alternatively, you could use a compare-exchange loop or a once flag.

[vstinner]

The commit 596cd5c introduced a reference leak:

$ ./python -m test test_free_threading -R 3:3 -m test.test_free_threading.test_sys.SysModuleTest.test_sys_audit_hooks
...
test_free_threading leaked [104, 104, 104] references, sum=312
...

The test calls sys.addaudithook(_hook) 100 times, and so changes an internal global list of hooks. But by design (for security), there is no API to unregister hooks. Usually, what's be done for audit tests is to run them in a subprocess. For example, test_audit runs each test in a subprocess.

[sobolevn]

Thank you @vstinner
I will fix that in #154494