On 04/12/2017 07:53 AM, Rainer Jung wrote:
The good news:

I checked by compiling your test program standalone (outside of
configure) to be able to run it easily very often (1000 times). I
checked on Solaris 8 (32 Bit) and 10 Sparc (32 Bit and 64 Bit) compilation.

When I compile without any flags, the test fails with return code 5,
when I compile with -D_REENTRANT it succeeds (rc 0). Since apr always
adds -D_REENTRANT for Solaris in build/apr_hints.m4 (independent of
APR_HAS_THREADS), and your test runs in httpd configure after apr
configure and thus inherits the flags, the test would correctly detect a
thread-safe errno for Solaris during configure.

Excellent. Thanks for the test!

The bad news:

If building httpd with apr/apu sources in srclib and using
--with-included-apr (and not assuming some unrelated installed system
APR), the test can't run, because the binary needs to get linked against
libapr-1 during configure runtime (where the lib has not yet been
build). I don't know how easy a non-apr using test would be that still
runs on the relevant target platforms :(

I was worried about that. I don't think it makes much sense to reimplement the portability layer just to get threads and locks for a configure test, especially if this problem is going to slowly disappear as people upgrade OpenSSL. Let me know if you have any good ideas, though...

Worst case, we don't run the test, and fall back to assuming &errno is unsafe. Then affected users either risk the crashes like they do today, or they set the cachevar manually to override the test.

It's probably worth noting at this point that, even if &errno is unsafe:

- Windows and BeOS users are still handled explicitly by default in 1.0.x.
- If OpenSSL still provides the deprecated CRYPTO_set_id_callback(), we can use it instead. We're not making use of the pointer-based THREADID implementation like we should be, heh, so we're not really getting a benefit out of the new system.
- This whole problem goes away in 1.1.x.

So the users who will still be affected are those who use OpenSSL 1.0.x, compiled with OPENSSL_NO_DEPRECATED, on platforms that don't pass (or can't run) our errno test. The only way to fix them is to pin the callback address somehow, and I'm not entirely sure it's worth the effort, if we're not currently seeing other reports of problems.

Side note:

I did increase NUM_THREADS to 10. But actually your original number of 3
gave the same results. Nevertheless I would increase the number if it is
OK for you (I know, quadratic behavior, but we shouldn't care too much
for this test):


Looks good to me, thanks! If you'd like, go ahead and check it into the trunk-openssl-threadid feature branch. Otherwise I'll plan to get around to it tomorrow.


Reply via email to