apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: 1.6.0 release candidates
Date Tue, 18 Apr 2017 21:13:19 GMT
Am 18.04.2017 um 16:25 schrieb Rainer Jung:
> Am 18.04.2017 um 00:16 schrieb Yann Ylavic:
>> Thanks Rainer for the detailed report (as usual).
>>
>> On Mon, Apr 17, 2017 at 2:01 PM, Rainer Jung <rainer.jung@kippdata.de>
>> wrote:
>>>
>>> c) Failure to compile apr on Solaris 8
>>> --------------------------------------
>>>
>>> Using gcc 4.1.2 compiling locks/unix/proc_mutex.c:
>>>
>>>  In function 'proc_mutex_pthread_create':
>>> 607: error: lvalue required as left operand of assignment
>>>  In function 'proc_mutex_pthread_acquire_ex':
>>> 711: error: lvalue required as left operand of assignment
>>> 790: warning: implicit declaration of function 'pthread_mutex_timedlock'
>>>  In function 'proc_mutex_pthread_release':
>>> 868: error: lvalue required as left operand of assignment
>>>  In function 'proc_mutex_pthread_cond_create':
>>> 945: error: lvalue required as left operand of assignment
>>>
>>> Concerning pthread_mutex_timedlock: that platform has
>>> HAVE_PTHREAD_CONDATTR_SETPSHARED set to 1 but
>>> HAVE_PTHREAD_MUTEX_TIMEDLOCK
>>> is not defined (and pthread_mutex_timedlock not available). So
>>> APR_USE_PROC_PTHREAD_MUTEX_COND is defined. So in line 688 we enter the
>>> "#else" branch which ends in line 815. That code includes a call to
>>> pthread_mutex_timedlock.
>>>
>>> Concerning the "lvalue required as left operand of assignment" the
>>> lines are
>>> always of the form
>>>
>>> proc_pthread_mutex_cond_locked(SOME_MUTEX) = SOME_INT;
>>>
>>> and proc_pthread_mutex_cond_locked(m) is defined as
>>>
>>> ((m)->pthread_refcounting ? proc_pthread_cast(m)->cond_locked : -1)
>>>
>>> which indeed doesn't look like a good lvalue.
>>
>> Sorry about that, I thought I had tested the
>> APR_USE_PROC_PTHREAD_MUTEX_COND case with some #undef's on Linux but
>> it seems I missed it for my latest changes.
>>
>> All the above hopefuly fixes with r1791718 and r1791728, both
>> backported to 1.6.x.
>
> Sorry to say that, but there's now another strange test result on
> Solaris 8. Again testprocmutex. It fails or mech "default_timed" in
> test_exclusive here:
>
>    209          rv = apr_proc_mutex_unlock(proc_lock);
>    210          APR_ASSERT_SUCCESS(tc, "unlock after timedlock check", rv);
>    211
>    212          *x = 0;
>    213
>    214          for (n = 0; n < CHILDREN; n++)
>    215              make_child(tc, -1, &child[n], p);
>    216
>    217          for (n = 0; n < CHILDREN; n++)
>    218              await_child(tc, child[n]);
>                     ^^^^^^^^^^^
>
> In await_child while waiting for the number 0 child, apr_proc_wait
> returns after 75 seconds with code 1.
>
> When I try t use truss, I had to terminate it after a few minutes,
> because it wasn't terminating by itself. I had about half 550.000
> lwp_mutex_lock and 590.000 lwp_mutex_unlock for each of the the 6
> threads, and also about 40.000 per thread of:
>
> lwp_cond_wait(0xFF040018, 0xFF040000, 0xFFBEF868) Err#62 ETIME
>
> Any idea what to look for in the condvar impl of the timedlock feature?

After disabling pthread_mutex_timedlock for Solaris 10, I get the same 
problem as described above. I also tried with Linux and had mixed 
results. One attempt on SLES 11 did not show the problem, another 
attempt with RHEL 7 did show the same problem.

The duration for which the await_process hangs varies, I saw 164 seconds 
on Solaris10 and 234 seconds for RHEL 7.

Regards,

Rainer

Mime
View raw message