Hi Nick,
Am 16.04.2017 um 01:12 schrieb Nick Kew:
Today I have tagged both APR and APR-UTIL 1.6.0
and rolled tarballs of release candidates in
the full choice of formats provided for 1.5.latest
on our pages.
Please download and test, from
http://people.apache.org/~niq/apr/
my test results: most important is failure to compile on Solaris 8 and a
hang during make test on Solaris 10, as well as your key seeming to be
revoked. See below.
1) Formal observations
======================
- MD5 and SHA1 missing
- zip archives not named "win32-src.zip" as previously
- CHANGES-APR-1.6 and CHANGES-APR-UTIL-1.6 missing
- HEADER.html and README.html missing
- Announcement1.6.txt and Announcement1.6.html missing
- Key B87F79A9 missing from KEYS file
- Key B87F79A9 is listed as "revoked: 2016-08-16" in key server
- ".svn" directory included, that's unusual
- STATUS file included, that's unusual
- Unix build files configure, *.spec, build-outputs.mk, build/*.sh,
build/l*.m4 (libtool m4 files) and the copies of the apr build/*.m4
in apu are included in zip (that's new, but IMHO OK)
- no more bundled expat: we need to note that in the release notes
2) Compile and run
==================
a) New apr configure options
----------------------------
--enable-allocator-guard-pages Use guard pages in apr_allocator
(implies --enable-allocator-uses-mmap)
--enable-pool-concurrency-check Check for concurrent usage of memory
pools
--with-valgrind[=DIR] Enable code to teach valgrind about apr pools
(optionally: set path to valgrind headers)
b) Changes in apr-util configure options
----------------------------------------
- new --with-commoncrypto=DIR specify location of CommonCrypto
- removed --with-freetds=DIR specify FreeTDS location
- changed --with-expat=DIR from "specify Expat location, or
'builtin'" to "specify Expat location"
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.
d) Hang during APR make check on Solaris 10 (testprocmutex)
-----------------------------------------------------------
pthread_mutex_timedlock() hangs when the current thread already has
locked the mutex.
GDB says:
#0 0xff14ca00 in ___lwp_mutex_timedlock () from /lib/libc.so.1
No symbol table info available.
#1 0xff13fde8 in mutex_lock_kernel () from /lib/libc.so.1
No symbol table info available.
#2 0xff140f4c in stall () from /lib/libc.so.1
No symbol table info available.
#3 0xff1416dc in mutex_lock_internal () from /lib/libc.so.1
No symbol table info available.
#4 0xff141cc0 in pthread_mutex_timedlock () from /lib/libc.so.1
No symbol table info available.
#5 0xff369310 in proc_mutex_pthread_acquire_ex (mutex=0xb4ff8,
timeout=1492421091353146)
at .../locks/unix/proc_mutex.c:790
abstime = {tv_sec = 1492421091, tv_nsec = 353146000}
rv = <optimized out>
#6 0xff36a500 in apr_proc_mutex_timedlock (mutex=0xb4ff8, timeout=1) at
.../locks/unix/proc_mutex.c:1558
No locals.
#7 0x00029f90 in test_exclusive (lockname=0x0, mech=0xffbffad8,
tc=0xffbffa70) at .../test/testprocmutex.c:197
child = {0xb5118, 0xb5128, 0xb5138, 0xb5148, 0xb5158, 0xb5168}
rv = 0
n = 0
#8 proc_mutex (tc=0xffbffa70, data=0xffbffad8) at
.../test/testprocmutex.c:243
rv = <optimized out>
shmname = 0x37ad0 "tpm.shm"
shm = 0xb4fc8
#9 0x00015a4c in abts_run_test (ts=ts@entry=0xb7b70, f=f@entry=0x29ccc
<proc_mutex>, value=value@entry=0xffbffad8)
at .../test/abts.c:171
tc = {failed = 0, suite = 0xb76a8}
ss = 0xb76a8
#10 0x0002a26c in testprocmutex (suite=0xb7b70) at
.../test/testprocmutex.c:274
lockmechs = {{num = APR_LOCK_DEFAULT, name = 0x37d70
"default"}, {num = APR_LOCK_SYSVSEM, name = 0x37d78 "sysvsem"}, {num =
APR_LOCK_POSIXSEM, name = 0x37d80 "posix"},
{num = APR_LOCK_FCNTL, name = 0x37d88 "fcntl"}, {num =
APR_LOCK_PROC_PTHREAD, name = 0x37d90 "proc_pthread"}, {num =
APR_LOCK_DEFAULT_TIMED,
name = 0x37da0 "default_timed"}}
#11 0x000336c0 in main (argc=2, argv=<optimized out>) at .../test/abts.c:429
i = <optimized out>
list_provided = <optimized out>
suite = 0xb7b70
and the timestamp given is Mon Apr 17 11:24:51 2017, which looks OK. So
for some reason the timedlock doesn't time out when trying to acquire
the proc_mutex a second time.
truss (Solaris variant of strace) shows for the first successful call:
lwp_mutex_timedlock(0xFF1D0000, 0xFFBFF880) = 0
mutex type: USYNC_PROCESS|LOCK_PRIO_INHERIT|LOCK_ROBUST
timeout: 0.000000000 sec
and then for the hanging subsequent call by the same thread:
lwp_mutex_timedlock(0xFF1D0000, 0xFFBFF880) Err#45 EDEADLK
mutex type: USYNC_PROCESS|LOCK_PRIO_INHERIT|LOCK_ROBUST
timeout: 0.000000000 sec
lwp_mutex_timedlock(0xFF1B5778, 0x00000000) (sleeping...)
mutex type: USYNC_THREAD
Assuming the Solaris code is similar to:
https://github.com/OpenIndiana/illumos-gate/blame/master/usr/src/lib/libc/port/threads/synch.c
maybe my Solaris 10 does not have the following code change in it:
https://github.com/OpenIndiana/illumos-gate/commit/f52756fb59521fc0f684db03ee24da2a1d12a52a
"6738798 pthread_mutex_timedlock can block forever when using priority
inherit mutexes"
When running the same testall binary on Solaris 11, I do not get these
hangs.
Unfortunately I was not (yet) able to find out, whether there's a patch
for Bug 6738798 available on Solaris 10, or whether we would break
Solaris 10.
3) Miscellanea
I have updated config.guess and config.sub in apr 1.6.x (and 1.5.x) but
the changes are not very important, so that would not be a reason to retag.
Regards and thanks for pushing this.
Rainer
