Data race in test_ssl.test_sni_callback_race

Bug report

There is a sporadic thread sanitizer reported data race in a newly added test

• GH-150018

For example:

• https://github.com/python/cpython/actions/runs/26217633343/job/77144045276

Here is a summary from Claude with my edits:

On the free-threaded TSAN build, test.test_ssl.ContextTests.test_sni_callback_race sporadically reports a data race inside OpenSSL: one thread reads an ASN.1 string via ASN1_STRING_cmp (no lock held) while another writes the same heap block via ASN1_STRING_set (holding an internal CRYPTO_THREAD_lock rwlock). The test itself does not crash.

Reproducer

CC=clang-20 ./configure -C --disable-gil --with-pydebug --with-thread-sanitizer
make -j

for i in $(seq 1 30); do
  TSAN_OPTIONS="halt_on_error=1" \
    ./python -m test test_ssl -v -m test_sni_callback_race > /tmp/run_$i.log 2>&1
  [ $? -ne 0 ] && echo "FAILED on run $i" && break
done

Reproduces within ~15 runs on a 22-core machine.

TSAN report (abridged)

WARNING: ThreadSanitizer: data race

  Read of size 8 by thread T11:
    #0 memcmp
    #1 ASN1_STRING_cmp           (libcrypto.so.3)
    ...
    #22 thread_run               Modules/_threadmodule.c:388

  Previous write of size 8 by thread T12 (mutexes: write M0):
    #0 memcpy
    #1 ASN1_STRING_set           (libcrypto.so.3)
    ...
    #22 thread_run               Modules/_threadmodule.c:388

  Location is heap block of size 21 allocated by ASN1_STRING_set
  Mutex M0 created by CRYPTO_THREAD_lock_new (libcrypto.so.3)

SUMMARY: ThreadSanitizer: data race in memcmp

The writer holds an OpenSSL-owned rwlock; the reader does not take the same lock. Both call sites enter from two Python worker threads doing concurrent SSL handshakes on the same SSLContext.

Environment

• CPython main @ c35b0f2b624 (3.16.0a0, free-threading debug TSAN)
• Clang 20.1.8
• OpenSSL 3.0.13 (30 Jan 2024)
• Linux 6.8.0-101 x86_64

cc @kiri11 @encukou

Linked PRs

• gh-150193
• gh-153269
• gh-153270
• gh-153320
• gh-153349
• gh-153350

Start with test_ssl.test_sni_callback_race and reproduce it using the free-threaded TSAN build command and repeated test runs described in the issue. Review the concurrent SSL handshakes on the shared SSLContext and the abridged TSAN report. Done means the test no longer reports the OpenSSL data race under the stated reproducer.