CI regression from the new hashtable support about openssl HOT 7 OPEN

Notes:
So....this is troubling
while looking for the root cause of this issue, I found that it was occuring in the test_hashtable_multithread test. Its really odd, because it appears we're getting random memory corruption during the test

Whats more odd is that hppa is built without thread support, so its all single threaded, which eliminates race conditions as a possible source of the problem.

Whats more odd is that, in this single threaded environment

Whats more odd is that if I reduce the optimization level to -O1, the problem abates

further reading shows that pa-risc has no hardware support for atomics, all atomic operations are by default implemented with the sync library, or optionally by libatomic. When using the latter several build errors are produced, so for now we appear stuck with the former

I'm starting to wonder if perhaps we're seeing a issue with atomic operations on an old arch that isn't as well maintained anymore

from openssl.

@nhorman Unfortunately the hppa cross-compile job is still not fixed:

https://github.com/openssl/openssl/actions/runs/8893580037/job/24420072833

from openssl.

will look at it, need to get a local reproducer setup

from openssl.

Hmm... I am wondering if we should just have much more simple fallback for atomics on no-thread builds? Of course another option is to just declare this platform unsupported and remove it from CI.

from openssl.

Possibly. I'd like to better understand the issue before we make a decision, but yeah, I think both of those options are on the table. It's also feasible that this is a compiler issue. One of the options for hppas compiler is -mnoindex-loads, which eliminates the use of indexed addressing mode in loads/stores to which this problem seems related to. Will let you know

from openssl.

I'm becoming increasingly convinced that this is a compiler bug.

My observations so far:

• Crashes happen in multiple places randomly (sometimes in do_mt_hash_work, sometimes in CRYPTO_atomic_add, sometimes in various other locations), but always as a subordonate of do_mt_hash_work
• The crashes happen normally because a register that holds the value needed for an indirect load is garbage
• Inspecting with gdb shows those registers always hold the result of an indexed load
• setting optimization for the function do_mt_hash_work to O1 makes the problem abate

Its also notable that this isn't a race condition as hppa build disables threading

from openssl.

Then add -O1 or something else that fixes the issue here as workaround:

from openssl.