`test_ssl` failures in free threading Windows optimized builds

[colesbury]

I'm seeing failures like:

test_load_dh_params (test.test_ssl.ContextTests.test_load_dh_params) ... OPENSSL_Uplink(00007FFCDC60CB00,08): no OPENSSL_Applink

The test then immediately exits.

I've seen this in the buildbots and when building locally on Windows:

https://buildbot.python.org/#/builders/1622/builds/1125

We don't see this in the GitHub actions CI because the relevant tests are skipped in debug builds:

cpython/Lib/test/test_ssl.py

Lines 1324 to 1325 in 8a00c9a

	@unittest.skipIf(Py_DEBUG_WIN32, "Avoid mixing debug/release CRT on Windows")
	def test_load_dh_params(self):

I don't think the relevant tests use threads at all -- it seems more likely to be a build issue than a multithreading issue.

cc @itamaro @zooba

[zooba]

Are you running the builds in a way that should also skip the test? Debug builds of CPython won't work properly with our pre-built OpenSSL

[colesbury]

These are optimized (non-debug) builds. Are our pre-built OpenSSL libraries incompatible with the free threading build?

[colesbury]

I'm running:

GOOD (default build):

PCBuild\build.bat -p x64

PCBUild\amd64\python.exe -m test test_ssl -m test_load_dh_params -v
== CPython 3.14.0a6+ (heads/main-dirty:8a00c9a4d2, Mar 27 2025, 20:50:22) [MSC v.1937 64 bit (AMD64)]
== Windows-2022Server-10.0.20348-SP0 little-endian
== Python build: release with_assert
== cwd: C:\Users\Administrator\cpython\build\test_python_worker_6296æ
== CPU count: 16
== encodings: locale=cp1252 FS=utf-8
== resources: all test resources are disabled, use -u option to unskip tests

Using random seed: 2875447533
0:00:00 Run 1 test sequentially in a single process
0:00:00 [1/1] test_ssl
test_ssl: testing with 'OpenSSL 3.0.15 3 Sep 2024' (3, 0, 0, 15, 0)
          under Windows ('2022Server', '10.0.20348', 'SP0', 'Multiprocessor Free')
          HAS_SNI = True
          OP_ALL = 0x80000050
          OP_NO_TLSv1_1 = 0x10000000
test_load_dh_params (test.test_ssl.ContextTests.test_load_dh_params) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.013s

OK
0:00:00 [1/1] test_ssl passed

BAD (--disable-gil build):

PCBuild\build.bat -p x64 --disable-gil

PCBUild\amd64\python3.14t.exe -m test test_ssl -m test_load_dh_params -v
== CPython 3.14.0a6+ experimental free-threading build (heads/main-dirty:8a00c9a4d2, Mar 27 2025, 20:53:18) [MSC v.1937 64 bit (AMD64)]
== Windows-2022Server-10.0.20348-SP0 little-endian
== Python build: free_threading GIL=1 release with_assert
== cwd: C:\Users\Administrator\cpython\build\test_python_worker_2508æ
== CPU count: 16
== encodings: locale=cp1252 FS=utf-8
== resources: all test resources are disabled, use -u option to unskip tests

Using random seed: 2518849569
0:00:00 Run 1 test sequentially in a single process
0:00:00 [1/1] test_ssl
test_ssl: testing with 'OpenSSL 3.0.15 3 Sep 2024' (3, 0, 0, 15, 0)
          under Windows ('2022Server', '10.0.20348', 'SP0', 'Multiprocessor Free')
          HAS_SNI = True
          OP_ALL = 0x80000050
          OP_NO_TLSv1_1 = 0x10000000
test_load_dh_params (test.test_ssl.ContextTests.test_load_dh_params) ... OPENSSL_Uplink(00007FFF33B9CB00,08): no OPENSSL_Applink

[colesbury]

Maybe this needs to handle the versioned _ssl.cp314t-win_amd64.pyd:

https://github.com/python/release-tools/blob/e2e4113c594b8d7062735f0c4b3e7057ed3483d8/windows-release/openssl-build.yml#L71

[zooba]

Maybe this needs to handle the versioned _ssl.cp314t-win_amd64.pyd:

Yeah, that'll be the problem. That's a shame, as it means we can't just use a single OpenSSL build for all our releases.

Maybe we need to drop the idea of installing binaries together and just require completely separate install directories. I'm happy enough with that once we drop the old installer, but I really don't want to spend the amount of time to get it working properly there.

Alternatively, if we push openssl/openssl#22209 through (and get it into an LTS release, whenever they anoint their next one), then we wouldn't need to patch it at all. Long-term that's definitely for the best. Or maybe we can patch the change into our own sources in https://github.com/python/cpython-source-deps/tree/openssl-3.0

[colesbury]

Can we do something silly like patch it try: _ssl.pyd, _ssl_d.pyd, _ssl.cp313t-win_amd64.pyd, ... _ssl.cp320t-win_amd64.pyd? That should cover us for a few years...

[zooba]

We need to patch for each platform, so that multiplies out pretty quick. It's easier just to add a commit to our sources with the real patch and remove the automatic one from that build script.

I'll take a look tomorrow

[zooba]

It looks like the easiest fix is to just disable applink entirely (which requires an OpenSSL rebuild), which should work fine for release builds (those that link to ucrtbase.dll rather than ucrtbased.dll).

We're due to rev the OpenSSL build anyway, so I'll do it. I'll make the functions that pass FILE * across DLL boundaries fail safely as well, since they'll crash hard without applink.