Hi Jacob,

Am 12.04.2017 um 02:16 schrieb Jacob Champion:
On 04/10/2017 03:59 PM, Jacob Champion wrote:
So it looks like my test program might still be a possible solution for
detecting whether we need a callback at configure time, unless anyone
knows of a platform where two thread-local errnos can have the same
address some of the time and different addresses at other times...

I've checked my first attempt into trunk. It writes the result into the
new AP_OPENSSL_USE_ERRNO_THREADID macro in ap_config_auto.h. On
platforms where every thread has its own errno address, that macro will
be #defined to 1.

Rainer, would you mind sanity-checking the result on your Solaris box
(sounds like the test should *not* pass there)? I've tested on Ubuntu
16.04, where the test passes.

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.

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 :(

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):

Index: trunk/acinclude.m4
--- trunk/acinclude.m4    (revision 1791085)
+++ trunk/acinclude.m4    (working copy)
@@ -653,7 +653,7 @@
           #include "apr_thread_cond.h"
           #include "apr_thread_proc.h"

-          #define NUM_THREADS 3
+          #define NUM_THREADS 10

           struct thread_data {
               apr_thread_mutex_t *mutex;
@@ -692,6 +692,7 @@
           int ret = 0;
           apr_status_t status;
           int i;
+          int j;

           apr_pool_t         *pool;
           apr_thread_mutex_t *mutex;
@@ -738,10 +739,13 @@

           /* Check that no addresses were duplicated. */
-          if ((tdata[0].errno_addr == tdata[1].errno_addr)
-              || (tdata[1].errno_addr == tdata[2].errno_addr)
-              || (tdata[0].errno_addr == tdata[2].errno_addr)) {
-              ret = 5;
+          for (i = 0; i < NUM_THREADS - 1; ++i) {
+              for (j = i + 1; j < NUM_THREADS; ++j) {
+                  if (tdata[i].errno_addr == tdata[j].errno_addr) {
+                      ret = 5;
+                      goto out;
+                  }
+              }


If there's anyone else who wouldn't mind updating and posting their
platform and test result, that would really help me figure out how
widespread the "problem" is. Remember to rebuild configure first! :)



Reply via email to