You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Nick Kew <ni...@apache.org> on 2017/04/15 23:12:41 UTC
1.6.0 release candidates
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/
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.04.2017 um 00:16 schrieb Yann Ylavic:
>> d) Hang during APR make check on Solaris 10 (testprocmutex)
>> -----------------------------------------------------------
>>
>> pthread_mutex_timedlock() hangs when the current thread already has locked
>> the mutex.
...
>> 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.
>
> Maybe we need to "#define APR_USE_PROC_PTHREAD_MUTEX_COND 0" for
> Solaris 10, and fall back to the generic implementation (spinning
> sleep)...
Oracle changed the bug id from 6738798 to 15502514. The bug isn't rated
high and the fix never got released for Solaris 10, so all Solaris 10
systems should be buggy.
The fix was included in Solaris 11, probably from the beginning, so
those systems should be OK.
So we either need to allow to disable the feature, or find a fix for it
(which IMHO is hard, because the hang happens before we can detect that
we will hang) or we disable the mutex_timedlock feature automatically
for Solaris 10. Based on the above status for Solaris 10, I am for
automatic disabling on Solaris 10 during configure time.
Regards,
Rainer
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@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.
The lvalue problem is gone in 1.6.x head, I can compile also on Solaris
8 (and still on my other test platforms).
Running make check, I get a core dump in testsock.c. In test_addr_copy
the initial
rv = apr_sockaddr_info_get(&sa1, *host, APR_UNSPEC, 80, 0, p);
APR_ASSERT_SUCCESS(tc, "Problem generating sockaddr", rv);
fails when host == "::1". In the following
rv = apr_sockaddr_info_copy(&sa2, sa1, p);
APR_ASSERT_SUCCESS(tc, "Problem copying sockaddr", rv);
sa1 is NULL and the copy results in a segmentation fault.
The copy functionality and the test is new in 1.6.x.
IMHO this is more a test problem and not an impl problem, sa1 being not
NULL is probably an expected prerequisite for the copy call.
I'll try to add some proper skip to the test if the
apr_sockaddr_info_get() fails.
I haven't yet tracked down, why this call fails for Solaris 8, but I am
not too concerned about IPv6 and ancient Solaris 8.
Regards,
Rainer
Re: 1.6.0 release candidates
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/20/2017 09:03 AM, Nick Kew wrote:
> On Wed, 2017-04-19 at 13:43 -0500, William A Rowe Jr wrote:
>> With patches now accounted for I can pre-test and report back today on
>> AIX, HPUX and propose a fix to silence the win32 32 -> 16 bit warnings
>> (after division is done.)
>
> Excellent. I look forward to your findings.
>
>> But my inclination is to defer this new feature to a later 1.7+2.0
>> release. Shipping a feature that devs would expect to need when it may
>> be largely unavailable seems a disservice to our end users and these
>> devs.
>
> I'd be fine with that. Or with the intermediate solution of
> switching from a --disable to a --enable option so it's
> disabled by default but minimal change to enable in 1.6.later.
> Anyone else have strong views?
>
No strong view, but if we defer to 1.7.x or 2.0, we are still free to do API changes or behavior changes
if it turns out that they are needed. If we are confident that the API contract is stable as such and
that we just need to fix bugs in the implementation on these platforms then go with 1.6.x with a default of off.
Regards
R�diger
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Wed, 2017-04-19 at 13:43 -0500, William A Rowe Jr wrote:
> With patches now accounted for I can pre-test and report back today on
> AIX, HPUX and propose a fix to silence the win32 32 -> 16 bit warnings
> (after division is done.)
Excellent. I look forward to your findings.
> But my inclination is to defer this new feature to a later 1.7+2.0
> release. Shipping a feature that devs would expect to need when it may
> be largely unavailable seems a disservice to our end users and these
> devs.
I'd be fine with that. Or with the intermediate solution of
switching from a --disable to a --enable option so it's
disabled by default but minimal change to enable in 1.6.later.
Anyone else have strong views?
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Sat, 6 May 2017 22:49:50 -0700
Gregg Smith <gl...@gknw.net> wrote:
> The one difference I see between 1.5 and 1.6 is testpipe of 1.6
Platform?
> Failed Tests Total Fail Failed %
> ===================================================
> testpipe 9 1 11.11%
>
> testpipe : |Line 161: expected <0>, but saw <22>
> FAILED 1 of 9
That's apr_file_pipe_timeout_set returning 22, which is presumably a
system error. Unix and netware may return an errno from fcntl,
and some beos (#if BEOS_BONE) might also return one from ioctl.
Windows and OS2 have no error returns in that range, as far as
I can tell.
So what is errno 22 on your platform? Here it's EINVAL, unless
some race condition has caught our scary use of errno.
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Gregg Smith <gl...@gknw.net>.
On 5/6/2017 2:59 PM, Nick Kew wrote:
> On Sat, 29 Apr 2017 12:23:52 +0100
> Nick Kew <ni...@apache.org> wrote:
>
> BTW, we could use reports from Windows, Netware and Beos on what
> works for you.
>
The one difference I see between 1.5 and 1.6 is testpipe of 1.6
Failed Tests Total Fail Failed %
===================================================
testpipe 9 1 11.11%
testpipe : |Line 161: expected <0>, but saw <22>
FAILED 1 of 9
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/07/2017 08:37 PM, Yann Ylavic wrote:
> On Sun, May 7, 2017 at 4:15 PM, Dennis Clarke <dc...@blastwave.org> wrote:
>>
>> node000 $ echo $CPPFLAGS
>> -I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO
>> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
> []
>>
>> During the compile is where we see every sort of non-portable warning or
>> error we can possibly imagine. Let's look at the few seconds that we
>> managed to get from it. In fact, even with a more relaxed compiler "cc"
>> we don't get very far.
>>
>> /usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=compile
>> /opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none -errshort=full
>> -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s -xnolibmil -Xa
>> -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy
>> -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
>> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H
>> -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include -I/usr/local/ssl/include
>> -I/usr/local/include/apr-1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS
>> -D_LARGEFILE64_SOURCE
>> -I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include
>> -I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include/private
>> -I/opt/mysql/mysql/include -I/usr/local/include/apr-1
>> -I/usr/local/ssl/include -I/usr/local/include -o
>> buckets/apr_buckets_file.lo -c buckets/apr_buckets_file.c && touch
>> buckets/apr_buckets_file.lo
>> "buckets/apr_buckets_file.c", line 112: error: undefined struct/union
>> member: read_size
>
> Looks like due to $CCPFLAGS above, an old
> "/usr/local/include/apr-1/apr_buckets.h" already exists and is
> prioritized over the one in
> "/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include".
>
I was thinking the same thing. I am going to spin up a fully separate
beta site to do this testing with. I want full isolation and to have
apr-1.6.0 sorted first and to remove the entire include directory
/usr/local/include/apr-1/ from the mix before starting. This is
the only way to clean out the old before working on the new.
Dennis
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/10/2017 01:37 PM, Nick Kew wrote:
> On Wed, 10 May 2017 14:05:51 +0100
> Nick Kew <ni...@apache.org> wrote:
>
>> But if you got through "configure" without it checking for expat,
>> you would seem to have found a bug.
>
> Whoops! That should have read one or the other of expat
> and libxml2, since those are now alternatives. But it seems
> that didn't get backported from 2.0/trunk.
>
> I don't think that's a showstopper, but a bad omission.
>
With a little hackary I am able to get past the stlport4 issues and deal
with the $ORIGIN libpath bits and get this :
beta $ diff /opt/mysql/mysql/bin/mysql_config.backup
/opt/mysql/mysql/bin/mysql_config
116c116
< libs="$libs -R'\$ORIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9"
---
> libs="$libs -R/opt/developerstudio12.5/lib/stlport4/sparcv9"
118c118
< libs_r="$libs_r -R'\$ORIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9"
---
> libs_r="$libs_r -R/opt/developerstudio12.5/lib/stlport4/sparcv9"
120c120
< embedded_libs="$embedded_libs -R'\$ORIGIN/../lib'
-R/opt/studio12u2/lib/stlport4/v9"
---
> embedded_libs="$embedded_libs
-R/opt/developerstudio12.5/lib/stlport4/sparcv9"
beta $
That should ( I think ) be harmless in that the real stlport4 libs are
really not in the /opt/studio12u2 path at all. This looks like once
again the Oracle devs left things behind in the libmysqlclient lib that
will break downstream binaries. Happened before.
We should be able to get by with just -L/opt/mysql/mysql/lib since the
libstlport4 libs are redistributable and yes they are in the MySQL
package :
beta $ ls -lap /opt/mysql/mysql/lib/libstlport*
lrwxrwxrwx 1 root root 36 May 7 22:36
/opt/mysql/mysql/lib/libstlport.so -> /opt/mysql/mysql/lib/libstlport.so.1
-rw-r--r-- 1 root bin 2483248 Aug 14 2010
/opt/mysql/mysql/lib/libstlport.so.1
beta $
However let's give this a try and we see a slight diff in configure
results :
beta $ diff ../apr-util-1.6.0_SunOS5.10_sparcv9.002.config.log
../apr-util-1.6.0_SunOS5.10_sparcv9.003.config.log
66,67c66,67
< setting LDFLAGS to "-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib
-R'$ORIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9"
< setting LIBS to "-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib
-lmysqlclient -lsocket -lnsl -lm -lrt -R'$ORIGIN/../lib'
-R/opt/studio12u2/lib/stlport4/v9"
---
> setting LDFLAGS to "-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib
-R/opt/developerstudio12.5/lib/stlport4/sparcv9"
> setting LIBS to "-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib
-lmysqlclient -lsocket -lnsl -lm -lrt
-R/opt/developerstudio12.5/lib/stlport4/sparcv9"
76c76
< setting LDADD_dbd_mysql to "-L/opt/mysql/mysql/lib
-R/opt/mysql/mysql/lib -R'$ORIGIN/../lib'
-R/opt/studio12u2/lib/stlport4/v9 -lmysqlclient -L/opt/mysql/mysql/lib
-R/opt/mysql/mysql/lib -lmysqlclient -lsocket -lnsl -lm -lrt
-R'$ORIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9"
---
> setting LDADD_dbd_mysql to "-L/opt/mysql/mysql/lib
-R/opt/mysql/mysql/lib
-R/opt/developerstudio12.5/lib/stlport4/sparcv9 -lmysqlclient
-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib -lmysqlclient -lsocket
-lnsl -lm -lrt -R/opt/developerstudio12.5/lib/stlport4/sparcv9"
beta $
Do the compile and we get to a point and then silently stop ?
.
.
.
/usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=compile
/opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-DHAVE_CONFIG_H -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include
-I/usr/local/ssl/include -I/usr/local/include/apr-1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.003/include
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.003/include/private
-I/opt/mysql/mysql/include -I/usr/local/include/apr-1
-I/usr/local/ssl/include -I/usr/local/include -o dbd/apr_dbd_sqlite3.lo
-c dbd/apr_dbd_sqlite3.c && touch dbd/apr_dbd_sqlite3.lo
/usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=link
/opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-L/usr/local/ssl/lib -L/usr/local/lib -release 1 -module -rpath
/usr/local/lib/apr-util-1 -o dbd/apr_dbd_sqlite3.la
dbd/apr_dbd_sqlite3.lo -lsqlite3
gmake[1]: Leaving directory
`/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.003'
beta $
So is that success ? Hard to say.
Run gmake check and I see :
/usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=link
/opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-DHAVE_CONFIG_H -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include
-I/usr/local/ssl/include -I/usr/local/include/apr-1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.003/include
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.003/include/private
-I/opt/mysql/mysql/include -I/usr/local/include/apr-1
-I/usr/local/ssl/include -I/usr/local/include -no-install
-L/usr/local/ssl/lib -L/usr/local/lib -o testall abts.lo testutil.lo
teststrmatch.lo testuri.lo testuuid.lo testbuckets.lo testpass.lo
testmd4.lo testmd5.lo testldap.lo testdate.lo testdbm.lo testdbd.lo
testxml.lo testrmm.lo testreslist.lo testqueue.lo testxlate.lo
testmemcache.lo testcrypto.lo testsiphash.lo testredis.lo
../libaprutil-1.la -lexpat -liconv /usr/local/lib/libapr-1.la -luuid
-lsendfile -lrt -lsocket -lnsl -lpthread
if test ! -d "./data"; then cp -r ./data data; fi
gmake[2]: Leaving directory
`/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.003/test'
teststatus=0; \
progfailed=""; \
for prog in dbd testall; do \
if test "$prog" = 'dbd'; then \
for driver in none mysql sqlite3; do \
if test "$driver" != 'none'; then \
LD_LIBRARY_PATH="`echo
"../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH"
| sed -e 's/::*$//'`" \
./$prog $driver; \
status=$?; \
if test $status != 0; then \
teststatus=$status; \
progfailed="$progfailed '$prog
$driver'"; \
fi; \
fi; \
done; \
else \
LD_LIBRARY_PATH="`echo
"../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH"
| sed -e 's/::*$//'`" \
./$prog; \
status=$?; \
if test $status != 0; then \
teststatus=$status; \
progfailed="$progfailed $prog"; \
fi; \
fi; \
done; \
if test $teststatus != 0; then \
echo "Programs failed:$progfailed"; \
fi; \
exit $teststatus
Loaded mysql driver OK.
Failed to open mysql[]
Loaded sqlite3 driver OK.
Opened sqlite3[] OK
======== create table ========
create table test successful
======== insert rows ========
insert rows test successful
======== invalid op ========
invalid op returned 1 (should be nonzero). Error msg follows
'no such table: apr_dbd_test1'
valid op returned 0 (should be zero; error shouldn't affect subsequent ops)
invalid op test successful
======== select random ========
ROW 5: wibble nothing 5
ROW 1: asdfgh bar 1
select random test successful
======== select sequential ========
ROW 1: asdfgh bar 1
ROW 2: bar foo (null)
ROW 3: foo (null) (null)
ROW 4: qwerty foo 0
ROW 5: wibble nothing 5
ROW 6: wibble other 5
select sequential test successful
======== transactions ========
Transaction 1
6 rows updated
Valid insert returned 1. Should be nonzero (fail) because transaction
is bad
Transaction ended (should be rollback) - viewing table
A column of "failed" indicates transaction failed (no rollback)
ROW 1: asdfgh bar 1
ROW 2: bar foo (null)
ROW 3: foo (null) (null)
ROW 4: qwerty foo 0
ROW 5: wibble nothing 5
ROW 6: wibble other 5
Transaction 2
6 rows updated
Valid insert returned 0. Should be zero (OK)
Transaction ended (should be commit) - viewing table
ROW 1: aaa zzz 3
ROW 2: asdfgh success 1
ROW 3: bar success (null)
ROW 4: foo success (null)
ROW 5: qwerty success 0
ROW 6: wibble success 5
ROW 7: wibble success 5
transactions test successful
======== prepared select ========
Selecting rows where col3 <= 3 and bar row where it's unset.
Should show four rows.
ROW 1: qwerty success 0
ROW 2: asdfgh success 1
ROW 3: bar success (null)
ROW 4: aaa zzz 3
prepared select test successful
======== prepared query ========
Showing table (should now contain row "prepared insert 2")
ROW 1: aaa zzz 3
ROW 2: asdfgh success 1
ROW 3: bar success (null)
ROW 4: foo success (null)
ROW 5: prepared insert 2
ROW 6: qwerty success 0
ROW 7: wibble success 5
ROW 8: wibble success 5
prepared query test successful
======== drop table ========
drop table test successful
teststrmatch : SUCCESS
testuri : SUCCESS
testuuid : SUCCESS
testbuckets : SUCCESS
testpass : SUCCESS
testmd4 : SUCCESS
testmd5 : SUCCESS
testcrypto : ld.so.1: testall: fatal: relocation error: file
testall: symbol apr_crypto_key: referenced symbol not found
/usr/local/bin/bash: line 2: 20338 Killed
LD_LIBRARY_PATH="`echo
"../crypto/.libs:../dbm/.libs:../dbd/.libs:../ldap/.libs:$LD_LIBRARY_PATH"
| sed -e 's/::*$//'`" ./$prog
Programs failed: testall
gmake[1]: *** [check] Error 137
gmake[1]: Leaving directory
`/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.003/test'
gmake: *** [check] Error 2
beta $
*sigh*
So .. getting closer.
Dennis
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/10/2017 01:05 PM, Nick Kew wrote:
> On Wed, 10 May 2017 11:33:13 +0000
> Dennis Clarke <dc...@blastwave.org> wrote:
>
>> So that seems to be gone from apr-1.6.0 and I hope expat-2.2.0 solves
>> the issue.
>
> Yep, that's (due to be) part of the release notes.
>
> But if you got through "configure" without it checking for expat,
> you would seem to have found a bug.
Let's look :
beta $ grep -i "expat" apr-1.6.0_SunOS5.10_sparcv9.001.config.log
nope ... nothing seen there.
I do have ( two flavours ) of libexpat in place and I should do a
check here on this beta box to verify that nothing requires the older
SONAME libexpat.so.0 and then get rid of it. Regardless expat.h is
nowhere to be seen ...
beta # ls -lap /usr/local/lib/libexpa*
-rw-r--r-- 1 root bin 652272 May 19 2013
/usr/local/lib/libexpat.a
-rwxr-xr-x 1 root bin 977 Aug 6 2016
/usr/local/lib/libexpat.la
lrwxrwxrwx 1 root root 17 May 10 13:13
/usr/local/lib/libexpat.so -> libexpat.so.1.6.0*
lrwxrwxrwx 1 root root 17 May 10 13:12
/usr/local/lib/libexpat.so.0 -> libexpat.so.0.5.0*
-rwxr-xr-x 1 root bin 493024 Feb 28 2013
/usr/local/lib/libexpat.so.0.5.0
lrwxrwxrwx 1 root root 17 May 10 13:12
/usr/local/lib/libexpat.so.1 -> libexpat.so.1.6.0*
-rwxr-xr-x 1 root bin 503920 May 19 2013
/usr/local/lib/libexpat.so.1.6.0
>
> Thanks for test-driving.
>
I am trying to get apache 2.4.25 up and running with the new apr bits
and all of these binaries are build debug ready and I have core services
in place. Therefore single stepping and other goodness is perfectly
possible. Even better is running in the foreground within the debugger
itself however that overhead is pretty massive.
Dennis
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/10/2017 01:37 PM, Nick Kew wrote:
> On Wed, 10 May 2017 14:05:51 +0100
> Nick Kew <ni...@apache.org> wrote:
>
>> But if you got through "configure" without it checking for expat,
>> you would seem to have found a bug.
>
> Whoops! That should have read one or the other of expat
> and libxml2, since those are now alternatives. But it seems
> that didn't get backported from 2.0/trunk.
>
> I don't think that's a showstopper, but a bad omission.
>
OKay .. past the libexpat issue and now I see :
/usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=compile
/opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-DHAVE_CONFIG_H -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include
-I/usr/local/ssl/include -I/usr/local/include/apr-1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.002/include
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.002/include/private
-I/opt/mysql/mysql/include -I/usr/local/include/apr-1
-I/usr/local/ssl/include -I/usr/local/include -o dbd/apr_dbd_mysql.lo
-c dbd/apr_dbd_mysql.c && touch dbd/apr_dbd_mysql.lo
"/opt/mysql/mysql/include/my_config.h", line 647: warning: macro
redefined: PACKAGE_NAME
"/opt/mysql/mysql/include/my_config.h", line 648: warning: macro
redefined: PACKAGE_STRING
"/opt/mysql/mysql/include/my_config.h", line 649: warning: macro
redefined: PACKAGE_TARNAME
"/opt/mysql/mysql/include/my_config.h", line 650: warning: macro
redefined: PACKAGE_VERSION
"dbd/apr_dbd_mysql.c", line 385: warning: statement not reached
/usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=link
/opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-L/usr/local/ssl/lib -L/usr/local/lib -release 1 -module -rpath
/usr/local/lib/apr-util-1 -o dbd/apr_dbd_mysql.la dbd/apr_dbd_mysql.lo
-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib -R'RIGIN/../lib'
-R/opt/studio12u2/lib/stlport4/v9 -lmysqlclient -L/opt/mysql/mysql/lib
-R/opt/mysql/mysql/lib -lmysqlclient -lsocket -lnsl -lm -lrt
-R'RIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9
libtool: link: only absolute run-paths are allowed
gmake[1]: *** [dbd/apr_dbd_mysql.la] Error 1
gmake[1]: Leaving directory
`/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.002'
gmake: *** [all-recursive] Error 1
beta $
This is being caused by some bizarre and strange things done by the
Oracle/MySQL folks where they seem to leave behind required paths such
as the /opt/studio12u2/lib/stlport4 stuff and the use of $ORIGIN.
This should be easy to get around but I may have to tweak a few things
in the MySQL 5.6.36 distribution released by Oracle.
Stay tuned ...
Dennis
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/10/2017 01:37 PM, Nick Kew wrote:
> On Wed, 10 May 2017 14:05:51 +0100
> Nick Kew <ni...@apache.org> wrote:
>
>> But if you got through "configure" without it checking for expat,
>> you would seem to have found a bug.
>
> Whoops! That should have read one or the other of expat
> and libxml2, since those are now alternatives. But it seems
> that didn't get backported from 2.0/trunk.
>
> I don't think that's a showstopper, but a bad omission.
>
Probably an easy fix.
I see this here :
old ( stable ) apr-util ) lib $INST/lib/libaprutil-1.so.0.5.4 requires
libexpat.so.1 => /usr/local/lib/libexpat.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libapr-1.so.0 => /usr/local/lib/libapr-1.so.0
libuuid.so.1 => /lib/64/libuuid.so.1
libsendfile.so.1 => /lib/64/libsendfile.so.1
librt.so.1 => /lib/64/librt.so.1
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libpthread.so.1 => /lib/64/libpthread.so.1
libc.so.1 => /lib/64/libc.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
libmp.so.2 => /lib/64/libmp.so.2
libscf.so.1 => /lib/64/libscf.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1
libm.so.2 => /lib/64/libm.so.2
So there we see expat but nothing to do with libxml2 at all.
I also have an old appendix that should have been cut out from way back
on bug 54735 ( ye password issue ) :
$INST/bin/htpasswd_bug54735 needs :
libaprutil-1.so.0 => /usr/local/lib/libaprutil-1.so.0
libexpat.so.0 => /usr/local/lib/libexpat.so.0 <-- old
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libapr-1.so.0 => /usr/local/lib/libapr-1.so.0
libresolv.so.2 => /lib/64/libresolv.so.2
libuuid.so.1 => /lib/64/libuuid.so.1
libsendfile.so.1 => /lib/64/libsendfile.so.1
librt.so.1 => /lib/64/librt.so.1
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libpthread.so.1 => /lib/64/libpthread.so.1
libc.so.1 => /lib/64/libc.so.1
libexpat.so.1 => /usr/local/lib/libexpat.so.1 <-- new
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
libmp.so.2 => /lib/64/libmp.so.2
libscf.so.1 => /lib/64/libscf.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1
libm.so.2 => /lib/64/libm.so.2
Requires both the old SONAME and the new. Uggg. I'll nuke that. The
correct htpasswd from 2.4.25 only needs libexpat :
$INST/bin/htpasswd needs :
libaprutil-1.so.0 => /usr/local/lib/libaprutil-1.so.0
libexpat.so.1 => /usr/local/lib/libexpat.so.1
libiconv.so.2 => /usr/local/lib/libiconv.so.2
libapr-1.so.0 => /usr/local/lib/libapr-1.so.0
So I will keep digging forwards here and the objective is to get
beta.genunix.com up and running on apache 2.4.25 with the new
apr/apr-util 1.6.x bits ... hopefully today would be nice :-)
Dennis
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Wed, 10 May 2017 14:05:51 +0100
Nick Kew <ni...@apache.org> wrote:
> But if you got through "configure" without it checking for expat,
> you would seem to have found a bug.
Whoops! That should have read one or the other of expat
and libxml2, since those are now alternatives. But it seems
that didn't get backported from 2.0/trunk.
I don't think that's a showstopper, but a bad omission.
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Wed, 10 May 2017 11:33:13 +0000
Dennis Clarke <dc...@blastwave.org> wrote:
> So that seems to be gone from apr-1.6.0 and I hope expat-2.2.0 solves
> the issue.
Yep, that's (due to be) part of the release notes.
But if you got through "configure" without it checking for expat,
you would seem to have found a bug.
Thanks for test-driving.
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/07/2017 08:37 PM, Yann Ylavic wrote:
> On Sun, May 7, 2017 at 4:15 PM, Dennis Clarke <dc...@blastwave.org> wrote:
>>
>> node000 $ echo $CPPFLAGS
>> -I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO
>> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
> []
>>
>> During the compile is where we see every sort of non-portable warning or
>> error we can possibly imagine. Let's look at the few seconds that we
>> managed to get from it. In fact, even with a more relaxed compiler "cc"
>> we don't get very far.
>>
>> /usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=compile
>> /opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none -errshort=full
>> -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s -xnolibmil -Xa
>> -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy
>> -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
>> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H
>> -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include -I/usr/local/ssl/include
>> -I/usr/local/include/apr-1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS
>> -D_LARGEFILE64_SOURCE
>> -I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include
>> -I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include/private
>> -I/opt/mysql/mysql/include -I/usr/local/include/apr-1
>> -I/usr/local/ssl/include -I/usr/local/include -o
>> buckets/apr_buckets_file.lo -c buckets/apr_buckets_file.c && touch
>> buckets/apr_buckets_file.lo
>> "buckets/apr_buckets_file.c", line 112: error: undefined struct/union
>> member: read_size
>
> Looks like due to $CCPFLAGS above, an old
> "/usr/local/include/apr-1/apr_buckets.h" already exists and is
> prioritized over the one in
> "/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include".
I setup a fresh beta site to work on the 1.6.x code and the apr seems to
build fine without even a single warning at all from the Oracle Studio
12.5 compilers. I have thus moved on to apr-util where I see that there
once was an installed expat.h in the default /usr/local/include/apr-1
but it no longer exists. I will build in libexpat separately and then
see if that satisfies the dependency :
/usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=compile
/opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-DHAVE_CONFIG_H -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include
-I/usr/local/ssl/include -I/usr/local/include/apr-1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.001/include
-I/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.001/include/private
-I/opt/mysql/mysql/include -I/usr/local/include/apr-1
-I/usr/local/ssl/include -I/usr/local/include -o xml/apr_xml.lo -c
xml/apr_xml.c && touch xml/apr_xml.lo
"xml/apr_xml.c", line 35: cannot find include file: <expat.h>
"xml/apr_xml.c", line 66: error: syntax error before or at: XML_Parser
"xml/apr_xml.c", line 67: error: incomplete struct/union/enum XML_Error:
xp_err
"xml/apr_xml.c", line 82: error: improper member use: cur_elem
"xml/apr_xml.c", line 154: error: improper member use: error
"xml/apr_xml.c", line 157: error: improper member use: p
"xml/apr_xml.c", line 160: error: improper member use: p
"xml/apr_xml.c", line 164: error: improper member use: p
"xml/apr_xml.c", line 165: error: improper member use: p
"xml/apr_xml.c", line 166: error: improper member use: p
"xml/apr_xml.c", line 172: error: improper member use: cur_elem
"xml/apr_xml.c", line 174: error: improper member use: cur_elem
"xml/apr_xml.c", line 174: error: improper member use: doc
"xml/apr_xml.c", line 178: error: improper member use: cur_elem
"xml/apr_xml.c", line 192: error: improper member use: cur_elem
"xml/apr_xml.c", line 208: error: improper member use: error
"xml/apr_xml.c", line 220: error: improper member use: p
"xml/apr_xml.c", line 223: error: improper member use: p
"xml/apr_xml.c", line 225: error: improper member use: doc
"xml/apr_xml.c", line 240: error: improper member use: p
"xml/apr_xml.c", line 284: error: improper member use: error
"xml/apr_xml.c", line 315: error: improper member use: error
"xml/apr_xml.c", line 327: error: improper member use: error
"xml/apr_xml.c", line 331: error: improper member use: cur_elem
"xml/apr_xml.c", line 331: error: improper member use: cur_elem
"xml/apr_xml.c", line 342: error: improper member use: error
"xml/apr_xml.c", line 345: error: improper member use: cur_elem
"xml/apr_xml.c", line 346: error: improper member use: p
"xml/apr_xml.c", line 357: error: improper member use: p
"xml/apr_xml.c", line 364: warning: implicit function declaration:
XML_ParserFree
"xml/apr_xml.c", line 364: error: undefined struct/union member: xp
"xml/apr_xml.c", line 365: error: improper member use: xp
"xml/apr_xml.c", line 384: warning: no explicit type given
"xml/apr_xml.c", line 384: error: syntax error before or at: *
"xml/apr_xml.c", line 384: warning: undefined or missing type for: int
"xml/apr_xml.c", line 393: error: improper member use: p
"xml/apr_xml.c", line 394: error: improper member use: doc
"xml/apr_xml.c", line 394: error: improper member use: doc
"xml/apr_xml.c", line 394: error: improper member use: doc
"xml/apr_xml.c", line 396: error: improper member use: doc
"xml/apr_xml.c", line 399: error: improper member use: doc
"xml/apr_xml.c", line 401: error: undefined struct/union member: xp
"xml/apr_xml.c", line 401: warning: implicit function declaration:
XML_ParserCreate
"xml/apr_xml.c", line 402: error: improper member use: xp
"xml/apr_xml.c", line 410: warning: implicit function declaration:
XML_SetUserData
"xml/apr_xml.c", line 410: error: improper member use: xp
"xml/apr_xml.c", line 411: warning: implicit function declaration:
XML_SetElementHandler
"xml/apr_xml.c", line 411: error: improper member use: xp
"xml/apr_xml.c", line 412: warning: implicit function declaration:
XML_SetCharacterDataHandler
"xml/apr_xml.c", line 412: error: improper member use: xp
"xml/apr_xml.c", line 424: warning: implicit function declaration:
XML_SetDefaultHandler
"xml/apr_xml.c", line 424: error: improper member use: xp
"xml/apr_xml.c", line 434: error: undefined struct/union member: xp
"xml/apr_xml.c", line 435: error: improper member use: error
"xml/apr_xml.c", line 438: warning: implicit function declaration: XML_Parse
"xml/apr_xml.c", line 438: error: improper member use: xp
"xml/apr_xml.c", line 441: error: improper member use: error
"xml/apr_xml.c", line 442: warning: implicit function declaration:
XML_GetErrorCode
"xml/apr_xml.c", line 442: error: improper member use: xp
"xml/apr_xml.c", line 447: error: improper member use: error
"xml/apr_xml.c", line 464: error: improper member use: p
"xml/apr_xml.c", line 470: error: improper member use: doc
"xml/apr_xml.c", line 478: error: improper member use: error
"xml/apr_xml.c", line 482: error: improper member use: error
"xml/apr_xml.c", line 500: warning: implicit function declaration:
XML_ErrorString
cc: acomp failed for xml/apr_xml.c
gmake[1]: *** [xml/apr_xml.lo] Error 1
gmake[1]: Leaving directory
`/usr/local/build/apr-util-1.6.0_SunOS5.10_sparcv9.001'
gmake: *** [all-recursive] Error 1
beta $
If I look at my running apache 2.4.25 sites I see :
node000 $ /usr/local/bin/httpd -V
Server version: Apache/2.4.25 (Unix)
Server built: Feb 15 2017 17:59:55
Server's Module Magic Number: 20120211:67
Server loaded: APR 1.5.1, APR-UTIL 1.5.3
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_PROC_PTHREAD_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/usr/local"
-D SUEXEC_BIN="/usr/local/bin/suexec"
-D DEFAULT_PIDLOG="www/var/logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="www/conf/mime.types"
-D SERVER_CONFIG_FILE="www/conf/httpd.conf"
Wherein :
node000 $ ls -lap /usr/local/include/apr-1/expat.h
-rw-r--r-- 1 root bin 39164 Feb 28 2013
/usr/local/include/apr-1/expat.h
So that seems to be gone from apr-1.6.0 and I hope expat-2.2.0 solves
the issue.
Dennis
Re: 1.6.0 release candidates
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, May 7, 2017 at 4:15 PM, Dennis Clarke <dc...@blastwave.org> wrote:
>
> node000 $ echo $CPPFLAGS
> -I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
[]
>
> During the compile is where we see every sort of non-portable warning or
> error we can possibly imagine. Let's look at the few seconds that we
> managed to get from it. In fact, even with a more relaxed compiler "cc"
> we don't get very far.
>
> /usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=compile
> /opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none -errshort=full
> -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s -xnolibmil -Xa
> -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy
> -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H
> -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include -I/usr/local/ssl/include
> -I/usr/local/include/apr-1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS
> -D_LARGEFILE64_SOURCE
> -I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include
> -I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include/private
> -I/opt/mysql/mysql/include -I/usr/local/include/apr-1
> -I/usr/local/ssl/include -I/usr/local/include -o
> buckets/apr_buckets_file.lo -c buckets/apr_buckets_file.c && touch
> buckets/apr_buckets_file.lo
> "buckets/apr_buckets_file.c", line 112: error: undefined struct/union
> member: read_size
Looks like due to $CCPFLAGS above, an old
"/usr/local/include/apr-1/apr_buckets.h" already exists and is
prioritized over the one in
"/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include".
Regards,
Yann.
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/07/2017 12:28 PM, Nick Kew wrote:
> On Sun, 7 May 2017 03:01:55 +0000
> Dennis Clarke <dc...@blastwave.org> wrote:
>
>
>> Where is this 1.6.0 tarball such that I may give it a careful build on
>> my Solaris servers ?
>>
>> I don't see it at http://archive.apache.org/dist/apr/
>
> http://apr.apache.org/dev/dist/
>
> Note: I just re-rolled those, cleaned up as per comments
> in this thread. The contents (code and build) are unchanged.
Awesome .. thank you.
> apr-1.6.0 has known problems and won't be released:
> we're looking to a 1.6.1.
Still a great idea to build it in a strict lab environment.
> apr-util-1.6.0 is, as far as we know, good to release, but
> waiting on an updated apr-1.6 candidate.
>
I will certainly give that a close look also.
>> I have very stable apache builds running in production and am certain
>> we can wring out what ever issue that may be in there with a pass
>> through the Oracle dev tools and strict c99 compiler. At the very
>> least I generally have debug builds wherein I can single step through
>> the resultant binaries if an issue does appear.
>
> Excellent, thanks!
No big surprises during configure with a strict C99 environment and very
strict CFLAGS :
node000 $ pwd
/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001
node000 $ date -u
Sun May 7 14:04:22 GMT 2017
node000 $ echo $CC
/opt/developerstudio12.5/bin/c99
node000 $ echo $CFLAGS
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc
-g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-xarch=sparc -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
node000 $ echo $CPPFLAGS
-I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
node000 $ echo $LD_OPTIONS
-64 -R/usr/local/lib -R/usr/local/ssl/lib -L/usr/local/lib
-L/usr/local/ssl/lib
node000 $ ./configure --prefix=/usr/local --with-apr=/usr/local \
> --with-crypto --with-openssl=/usr/local/ssl \
> --with-mysql=/opt/mysql/mysql --with-iconv=/usr/local \
> | tee ../apr-util-1.6.0_beta_SunOS5.10_sparcv9.001.config.log 2>&1
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
checking for a BSD-compatible install... build/install.sh -c
checking for working mkdir -p... yes
APR-util Version: 1.6.0
checking for chosen layout... apr-util
checking for gcc... /opt/developerstudio12.5/bin/c99
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether /opt/developerstudio12.5/bin/c99 accepts -g... yes
checking for /opt/developerstudio12.5/bin/c99 option to accept ISO
C89... none needed
Applying apr-util hints file rules for sparc-sun-solaris2.10
setting apu_iconv_inbuf_const to "1"
setting apu_crypt_threadsafe to "1"
checking for library containing fdatasync... none required
checking for APR... yes
setting CPP to "/opt/developerstudio12.5/bin/cc -E"
adding "-DSOLARIS2=10" to CPPFLAGS
adding "-D_REENTRANT" to CPPFLAGS
checking how to run the C preprocessor... /opt/developerstudio12.5/bin/cc -E
checking for grep that handles long lines and -e... /usr/local/bin/grep
checking for egrep... /usr/local/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
setting LDFLAGS to "-L/usr/local/ssl/lib "
configure: checking for openssl in /usr/local/ssl
checking openssl/x509.h usability... yes
checking openssl/x509.h presence... yes
checking for openssl/x509.h... yes
checking for EVP_CIPHER_CTX_new in -lcrypto... yes
checking for SSL_accept in -lssl... yes
setting APRUTIL_LDFLAGS to "-L/usr/local/ssl/lib"
setting APRUTIL_INCLUDES to "-I/usr/local/ssl/include"
checking whether EVP_PKEY_CTX_new is declared... yes
setting LDADD_crypto_openssl to "-L/usr/local/ssl/lib -lssl -lcrypto"
checking for const input buffers in OpenSSL... yes
checking for ldap support...
checking for default DBM... sdbm (default)
checking for pg_config... /usr/bin/pg_config
adding "-I/usr/include/pgsql" to CPPFLAGS
setting LDFLAGS to "-L/usr/lib"
checking libpq-fe.h usability... yes
checking libpq-fe.h presence... yes
checking for libpq-fe.h... yes
checking for PQsendQueryPrepared in -lpq... no
setting LIBS to "-lpgport -lpam -lssl -lcrypto -lz -ledit -ltermcap
-lrt -lresolv -lgen -lsocket -lnsl -ldl -lm "
checking for PQsendQueryPrepared in -lpq... no
checking postgresql/libpq-fe.h usability... no
checking postgresql/libpq-fe.h presence... no
checking for postgresql/libpq-fe.h... no
checking for mysql_config... /opt/mysql/mysql/bin/mysql_config
adding "-I/opt/mysql/mysql/include" to CPPFLAGS
setting LDFLAGS to "-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib
-R'$ORIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9"
setting LIBS to "-L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib
-lmysqlclient -lthread -lsocket -lnsl -lm -lrt -R'$ORIGIN/../lib'
-R/opt/studio12u2/lib/stlport4/v9"
configure: checking for mysql in /opt/mysql/mysql
checking for mysql.h... yes
checking for mysql_init in -lmysqlclient... yes
checking for my_global.h... yes
checking for mysql_init in -lmysqlclient... (cached) yes
checking for my_sys.h... yes
checking for mysql_init in -lmysqlclient... (cached) yes
adding "-I/opt/mysql/mysql/include" to APRUTIL_PRIV_INCLUDES
setting LDADD_dbd_mysql to "-L/opt/mysql/mysql/lib
-R/opt/mysql/mysql/lib -R'$ORIGIN/../lib'
-R/opt/studio12u2/lib/stlport4/v9 -lmysqlclient -L/opt/mysql/mysql/lib
-R/opt/mysql/mysql/lib -lmysqlclient -lthread -lsocket -lnsl -lm -lrt
-R'$ORIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9"
checking sqlite3.h usability... yes
checking sqlite3.h presence... yes
checking for sqlite3.h... yes
checking for sqlite3_open in -lsqlite3... yes
setting LDADD_dbd_sqlite3 to " -lsqlite3"
checking sqlite.h usability... no
checking sqlite.h presence... no
checking for sqlite.h... no
checking for odbc_config... no
checking sql.h usability... no
checking sql.h presence... no
checking for sql.h... no
checking odbc/sql.h usability... no
checking odbc/sql.h presence... no
checking for odbc/sql.h... no
checking Expat 1.95.x... yes
setting APRUTIL_EXPORT_LIBS to "-lexpat"
setting APRUTIL_LIBS to "-lexpat"
setting LDFLAGS to "-L/usr/local/lib"
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
setting LIBS to "-liconv"
adding "-liconv" to APRUTIL_LIBS
adding "-liconv" to APRUTIL_EXPORT_LIBS
nulling LIBS
removed "-I/usr/local/include" from CPPFLAGS
nulling LDFLAGS
adding "-I/usr/local/include" to APRUTIL_INCLUDES
adding "-L/usr/local/lib" to APRUTIL_LDFLAGS
checking for type of inbuf parameter to iconv... const char **
checking for iconv.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking for nl_langinfo... yes
checking for CODESET in langinfo.h... yes
checking whether APR has DSO support... yes
checking for library containing crypt... none required
checking if system crypt() function is threadsafe... yes
checking for crypt_r... no
checking whether the compiler handles weak symbols... yes
checking for memset_s support... no
checking for explicit_bzero support... no
adding "/usr/local/lib/libapr-1.la" to APRUTIL_LIBS
adding "-luuid" to APRUTIL_LIBS
adding "-lsendfile" to APRUTIL_LIBS
adding "-lrt" to APRUTIL_LIBS
adding "-lsocket" to APRUTIL_LIBS
adding "-lnsl" to APRUTIL_LIBS
adding "-lpthread" to APRUTIL_LIBS
configure: creating ./config.status
config.status: creating Makefile
config.status: creating export_vars.sh
config.status: creating build/pkg/pkginfo
config.status: creating apr-util.pc
config.status: creating apu-1-config
config.status: creating include/private/apu_select_dbm.h
config.status: creating include/apr_ldap.h
config.status: creating include/apu.h
config.status: creating include/apu_want.h
config.status: creating test/Makefile
config.status: creating include/private/apu_config.h
config.status: executing default commands
node000 $
During the compile is where we see every sort of non-portable warning or
error we can possibly imagine. Let's look at the few seconds that we
managed to get from it. In fact, even with a more relaxed compiler "cc"
we don't get very far.
/usr/local/bin/bash /usr/local/build-1/libtool --silent --mode=compile
/opt/developerstudio12.5/bin/cc -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xarch=sparc -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-DHAVE_CONFIG_H -DSOLARIS2=10 -D_REENTRANT -I/usr/local/include
-I/usr/local/ssl/include -I/usr/local/include/apr-1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include
-I/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001/include/private
-I/opt/mysql/mysql/include -I/usr/local/include/apr-1
-I/usr/local/ssl/include -I/usr/local/include -o
buckets/apr_buckets_file.lo -c buckets/apr_buckets_file.c && touch
buckets/apr_buckets_file.lo
"buckets/apr_buckets_file.c", line 112: error: undefined struct/union
member: read_size
"buckets/apr_buckets_file.c", line 112: error: improper member use:
read_size
"buckets/apr_buckets_file.c", line 166: error: undefined struct/union
member: read_size
"buckets/apr_buckets_file.c", line 205: error: undefined struct/union
member: read_size
"buckets/apr_buckets_file.c", line 208: warning: implicit function
declaration: apr_bucket_alloc_aligned_floor
"buckets/apr_buckets_file.c", line 209: error: undefined struct/union
member: read_size
cc: acomp failed for buckets/apr_buckets_file.c
gmake[1]: *** [buckets/apr_buckets_file.lo] Error 1
gmake[1]: Leaving directory
`/usr/local/build/apr-util-1.6.0_beta_SunOS5.10_sparcv9.001'
gmake: *** [all-recursive] Error 1
node000 $
Looking in the Makefile I see some ungodly references to libstlport for
some reason :
LDADD_dbd_mysql = -L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib
-R'$ORIGIN/../lib' -R/opt/studio12u2/lib/stlport4/v9 -lmysqlclient -
L/opt/mysql/mysql/lib -R/opt/mysql/mysql/lib -lmysqlclient -lthread
-lsocket -lnsl -lm -lrt -R'$ORIGIN/../lib' -R/opt/studio12u2/lib
/stlport4/v9
Not sure where that is coming from ... I'll dig around a bit.
Dennis
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Sun, 7 May 2017 03:01:55 +0000
Dennis Clarke <dc...@blastwave.org> wrote:
> On 05/07/2017 12:54 AM, William A Rowe Jr wrote:
> > So my blocking concern is that APR has never shipped an unready,
> > disabled by default feature. I don't mind not ready for prime time
> > but we traditionally called such things alpha or beta releases. I
> > am not worried about a specific platform, but about the wide range
> > of unreviewed architectures.
>
> I do mind shipping not ready for production prime time.
Even a feature labelled as "unready, do not use unless you're
prepared to hack it"?
> Where is this 1.6.0 tarball such that I may give it a careful build on
> my Solaris servers ?
>
> I don't see it at http://archive.apache.org/dist/apr/
http://apr.apache.org/dev/dist/
Note: I just re-rolled those, cleaned up as per comments
in this thread. The contents (code and build) are unchanged.
apr-1.6.0 has known problems and won't be released:
we're looking to a 1.6.1.
apr-util-1.6.0 is, as far as we know, good to release, but
waiting on an updated apr-1.6 candidate.
> I have very stable apache builds running in production and am certain
> we can wring out what ever issue that may be in there with a pass
> through the Oracle dev tools and strict c99 compiler. At the very
> least I generally have debug builds wherein I can single step through
> the resultant binaries if an issue does appear.
Excellent, thanks!
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Dennis Clarke <dc...@blastwave.org>.
On 05/07/2017 12:54 AM, William A Rowe Jr wrote:
> So my blocking concern is that APR has never shipped an unready,
> disabled by default feature. I don't mind not ready for prime time but
> we traditionally called such things alpha or beta releases. I am not
> worried about a specific platform, but about the wide range of
> unreviewed architectures.
I do mind shipping not ready for production prime time.
> The Solaris report seemed concerning.
Where is this 1.6.0 tarball such that I may give it a careful build on
my Solaris servers ?
I don't see it at http://archive.apache.org/dist/apr/
I have very stable apache builds running in production and am certain
we can wring out what ever issue that may be in there with a pass
through the Oracle dev tools and strict c99 compiler. At the very least
I generally have debug builds wherein I can single step through the
resultant binaries if an issue does appear.
Dennis
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
So my blocking concern is that APR has never shipped an unready, disabled
by default feature. I don't mind not ready for prime time but we
traditionally called such things alpha or beta releases. I am not worried
about a specific platform, but about the wide range of unreviewed
architectures.
The Solaris report seemed concerning. Many of my AIX observations were
incorrect libtool flavor detection for DSO and subordinate test program
invocation, but some weren't. (Can't test if mutex returns immediately.) I
will know Tues if this is entirety a regression or anticipated exception.
I'm afraid BEOS may already be abandoned. The comments about windows
specifics were also concerning, but I have to change gears Sunday back into
that world to start further review.
In short, everything excluding tiimedlock mutexed seems long overdue. This
new mutex feature extension seems hardly ready. I am -1 to have a default
disabled feature, and -0 on releasing this code in its present state.
Suspect it could use a couple months on the bench and a couple more active
reviewers on a breadth of platforms to move it on to a 1.7/2.0 release.
Just my thoughts, excepting your commit inverting a disable for an enable
flag. I think we should finish 1.6 immediately upon reverting this feature
on this branch, which means first forking to 1.7 to preserve it for another
minor release in the not too distant future.
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Sat, 29 Apr 2017 12:23:52 +0100
Nick Kew <ni...@apache.org> wrote:
> > Failed Tests Total Fail Failed %
> > ===================================================
> > testdso 9 8 88.89%
> > testprocmutex 6 3 50.00%
> > testsock 16 2 12.50%
> This is quite a lot to digest. Would it be fair to
> assume that anything outside those failed tests is
> unlikely to be an actual regression from 1.5.x?
We're currently blocking on these. It would be good
to unblock! I'm mostly concerned right now about
whether any of those failures indicates a regression.
I've worked through a diff against 1.5.2 (r1676021)
and looked for changes to any of those modules that might
conceivably be the cause of a regression.
Here's what I find:
1. TESTDSO
No changes whatsoever in code related to DSO
2. TESTSOCK: r1733452, r1733595.
network_io/unix/sockopt.c:
include/apr_network_io.h
test/testsock.c
Adds a case APR_SO_FREEBIND.
This looks unlikely to be a regression candidate
Is the new FREEBIND test one of the failures?
Any clue about the other?
3. TESTPROCMUTEX
locks/unix/proc_mutex.c
locks/unix/global_mutex.c
locks/unix/thread_cond.c
include/apr_proc_mutex.h
include/arch/unix/apr_arch_proc_mutex.h
Extensive changes with (some) consequences already discussed.
Any errors due to timedlock should be discounted: we'll add a
release note about "don't use unless prepared to work on it".
Are there any errors without timedlocks?
BTW, we could use reports from Windows, Netware and Beos on what
works for you.
--
Nick Kew
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Apr 29, 2017 at 12:50 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Not certain yet but the newly failing dso tests might be the application of
> LIBPATH in place of LD_LIBRARY_PATH. The new socket test failures are likely
> sctp discord. The new procmutex failures and failure messages about locking
> returning immediately worries me.
Found it, older libtool flavor knew aix5 not aix6, shlibpath_var
unknown. So that's
the 80/20 of failures and will report back what remains troublesome.
Reminds us tp future-proof, stupid to look for os{n} and not os{n..x} where
n is the current version and x is some distant version which should be
expected to work the same way, until it's discovered that it does not. The
earlier test forced the OS host evalutation to aix5.
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Apr 29, 2017 7:24 AM, "Nick Kew" <ni...@apache.org> wrote:
On Fri, 2017-04-28 at 11:35 -0500, William A Rowe Jr wrote:
> ./configure --enable-timedlocks
>
> Right off the bat we find new rpm hokum in our configure;
Where does the rpm_share come from? Isn't tar a complete red herring?
And grep -R doesn't find init_baselib either.
> make test is a bit of a mess, here are just the stderr observations;
OK, actual errors are presumably the place to look for what might
be actual regressions. In summary:
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 9 8 88.89%
> testprocmutex 6 3 50.00%
> testsock 16 2 12.50%
> The less-than-straightforward build is due to crazy AIX
> quirks convincing their xlc/ccs toolchains to emit anything
> that is 64 bit on a 64 bit build box;
You've evidently worked around it. Is that a fix you can apply
in our build (from trunk or otherwise), or is it better left
as a release note?
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 9 8 88.89%
> testprocmutex 6 3 50.00%
> testsock 16 2 12.50%
So no change there. Good.
> The obvious question, what is new since 1.5.2? New tests,
> for one, new misbehavior as well; the prior results from
> a recent product build with APR 1.5.2;
This is quite a lot to digest. Would it be fair to
assume that anything outside those failed tests is
unlikely to be an actual regression from 1.5.x?
Not certain yet but the newly failing dso tests might be the application of
LIBPATH in place of LD_LIBRARY_PATH. The new socket test failures are
likely sctp discord. The new procmutex failures and failure messages about
locking returning immediately worries me.
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Fri, 2017-04-28 at 11:35 -0500, William A Rowe Jr wrote:
> ./configure --enable-timedlocks
>
> Right off the bat we find new rpm hokum in our configure;
Where does the rpm_share come from? Isn't tar a complete red herring?
And grep -R doesn't find init_baselib either.
> make test is a bit of a mess, here are just the stderr observations;
OK, actual errors are presumably the place to look for what might
be actual regressions. In summary:
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 9 8 88.89%
> testprocmutex 6 3 50.00%
> testsock 16 2 12.50%
> The less-than-straightforward build is due to crazy AIX
> quirks convincing their xlc/ccs toolchains to emit anything
> that is 64 bit on a 64 bit build box;
You've evidently worked around it. Is that a fix you can apply
in our build (from trunk or otherwise), or is it better left
as a release note?
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 9 8 88.89%
> testprocmutex 6 3 50.00%
> testsock 16 2 12.50%
So no change there. Good.
> The obvious question, what is new since 1.5.2? New tests,
> for one, new misbehavior as well; the prior results from
> a recent product build with APR 1.5.2;
This is quite a lot to digest. Would it be fair to
assume that anything outside those failed tests is
unlikely to be an actual regression from 1.5.x?
--
Nick Kew
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Apr 26, 2017 at 4:07 AM, Nick Kew <ni...@apache.org> wrote:
>
> A minimalist approach is Good. But when you say minimalist, do you
> mean minimalist efforts as in "this should work out-of-the-box"
> or minimalist efforts as in a README.platform? Are we likely
> looking at more code commits?
Point of reference, I've ever bothered with gcc on AIX or HPUX, simply
use native compilers and linkers, but either aught to work.
Starting minimalist on AIX6.1, enabling timedlocks. Both the gnu
toolchain in freeware as well as the modern xlc compiler are all in the
path;
PATH=/usr/vac/bin:/usr/ccs/bin:/usr/local/bin:/opt/freeware/bin:/usr/sbin:/usr/bin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java6_64/bin
./configure --enable-timedlocks
Right off the bat we find new rpm hokum in our configure;
rpm_share: 0645-025 Unable to locate command module tar.
rpm_share: 0645-007 ATTENTION: init_baselib() returned an unexpected result.
(there is IBM tar as well as gtar in that path). These are just unwarranted
stderr warnings, so no crisis yet. gcc/gnu toolchain is detected
build is successful, no warnings or errors.
make test is a bit of a mess, here are just the stderr observations;
Line 61: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 77: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 102: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 126: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 147: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 163: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 188: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 212: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 93: Creation of large file (rlimit, quota or fs)
Line 114: Large file tests not enabled
Line 133: Large file tests not enabled
Line 146: Large file tests not enabled
Line 204: Large file tests not enabled
Line 179: Large file tests not enabled
Line 232: Large file tests not enabled
Line 259: Large file tests not enabled
Line 286: Large file tests not enabled
Line 302: Large file tests not enabled
Line 584: pollcb interface not supported
Line 611: pollcb interface not supported
Line 637: pollcb interface not supported
Line 653: pollcb interface not supported
Line 836: pollcb interface not supported
Line 733: pollcb interface not supported
Line 206: default_timedlock() should time out => Connection timed out
Line 206: sysvsem_timedlock() should time out => Connection timed out
Line 206: default_timed_timedlock() should time out => Connection timed out
Line 116: Problem generating sockaddr (670008): Hostname and service
name not provided or found
Line 389: expected something other than <0>, but saw <0>
Line 433: Cannot test if connect completes synchronously
Line 84: TCP isn't corkable
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 2.
Stop.
The stdout test results;
teststatus=0; progfailed=""; for prog in testlockperf
testmutexscope testall sendfile ; do if test "$prog" = 'sendfile';
then for mode in blocking nonblocking timeout; do ./$prog client
$mode startserver 127.0.0.1; status=$?; if test $status != 0; then
teststatus=$status; progfailed="$progfailed '$prog mode $mode'"; fi;
done; else ./$prog -v; status=$?; if test $status != 0; then
teststatus=$status; progfailed="$progfailed $prog"; fi; fi; done;
if test $teststatus != 0; then echo "Programs failed:$progfailed";
fi; exit $teststatus
APR Lock Performance Test
==============
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 1 threads OK
microseconds: 278207 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 1 threads OK
microseconds: 287077 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 1 threads OK
microseconds: 1356383 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 1 threads OK
microseconds: 398026 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 2 threads OK
microseconds: 1808399 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 2 threads OK
microseconds: 2053316 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 2 threads OK
microseconds: 1595797 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 2 threads OK
microseconds: 2207305 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 3 threads OK
microseconds: 2026627 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 3 threads OK
microseconds: 2038563 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 3 threads OK
microseconds: 2380387 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 3 threads OK
microseconds: 7393111 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 4 threads OK
microseconds: 2756837 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 4 threads OK
microseconds: 2667726 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 4 threads OK
microseconds: 3643844 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 4 threads OK
microseconds: 19533536 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 5 threads OK
microseconds: 4020024 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 5 threads OK
microseconds: 3701148 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 5 threads OK
microseconds: 3501648 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 5 threads OK
microseconds: 30114925 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 6 threads OK
microseconds: 3502252 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 6 threads OK
microseconds: 4914747 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 6 threads OK
microseconds: 4248309 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 6 threads OK
microseconds: 38295396 usec
Trying proc mutexes with mechanism `default'...
mutex mechanism `default' is global in scope on this platform.
Trying global mutexes with mechanism `default'...
no problem encountered...
Trying proc mutexes with mechanism `sysvsem'...
mutex mechanism `sysvsem' is global in scope on this platform.
Trying global mutexes with mechanism `sysvsem'...
no problem encountered...
Trying proc mutexes with mechanism `posix'...
mutex mechanism `posix' is global in scope on this platform.
Trying global mutexes with mechanism `posix'...
no problem encountered...
Trying proc mutexes with mechanism `fcntl'...
mutex mechanism `fcntl' is *NOT* global in scope on this platform.
Trying global mutexes with mechanism `fcntl'...
no problem encountered...
Trying proc mutexes with mechanism `proc_pthread'...
mutex mechanism `proc_pthread' is global in scope on this platform.
Trying global mutexes with mechanism `proc_pthread'...
no problem encountered...
Trying proc mutexes with mechanism `default_timed'...
mutex mechanism `default_timed' is global in scope on this platform.
Trying global mutexes with mechanism `default_timed'...
no problem encountered...
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testescape : SUCCESS
testfile : SUCCESS
testfilecopy : SUCCESS
testfileinfo : SUCCESS
testflock : SUCCESS
testfmt : SUCCESS
testfnmatch : SUCCESS
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testcond : SUCCESS
testlfs : SUCCESS
testmmap : SUCCESS
testnames : SUCCESS
testoc : SUCCESS
testpath : SUCCESS
testpipe : SUCCESS
testpoll : SUCCESS
testpools : SUCCESS
testproc : SUCCESS
testprocmutex : FAILED 3 of 6
testrand : SUCCESS
testsleep : SUCCESS
testshm : SUCCESS
testsock : FAILED 2 of 16
testsockets : SUCCESS
testsockopt : SUCCESS
teststr : SUCCESS
teststrnatcmp : SUCCESS
testtable : SUCCESS
testtemp : SUCCESS
testthread : SUCCESS
testtime : SUCCESS
testud : SUCCESS
testuser : SUCCESS
testvsn : SUCCESS
testskiplist : SUCCESS
Failed Tests Total Fail Failed %
===================================================
testdso 9 8 88.89%
testprocmutex 6 3 50.00%
testsock 16 2 12.50%
The less-than-straightforward build is due to crazy AIX
quirks convincing their xlc/ccs toolchains to emit anything
that is 64 bit on a 64 bit build box;
MAKE=gmake NM="nm -B -X64" AR="ar -X64" CC="xlc_r -qarch=pwr5
-qtune=pwr6 -q64" LD="xlc_r -qarch=pwr5 -qtune=pwr6 -q64" CFLAGS="-O2
-qmaxmem=32768 -g " LDFLAGS="-Wl,-brtl" SH_LDFLAGS="-G"
../apr-1.6/configure --build=powerpc64-ibm-aix6.1.6.0 --without-gnu-ld
--enable-timedlocks
Problems seem to lie in sctp.h again;
configure: WARNING: netinet/sctp.h: present but cannot be compiled
configure: WARNING: netinet/sctp.h: check for missing prerequisite headers?
configure: WARNING: netinet/sctp.h: see the Autoconf documentation
configure: WARNING: netinet/sctp.h: section "Present But Cannot Be Compiled"
configure: WARNING: netinet/sctp.h: proceeding with the preprocessor's result
configure: WARNING: netinet/sctp.h: in the future, the compiler will
take precedence
configure: WARNING: ## ------------------------------------------ ##
configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ##
configure: WARNING: ## ------------------------------------------ ##
The actual delta between the two configure attempts;
$ diff gcc.configure.log xlc.configure.log
1,3c1,3
< checking build system type... powerpc-ibm-aix6.1.6.0
< checking host system type... powerpc-ibm-aix6.1.6.0
< checking target system type... powerpc-ibm-aix6.1.6.0
---
> checking build system type... powerpc64-ibm-aix6.1.6.0
> checking host system type... powerpc64-ibm-aix6.1.6.0
> checking target system type... powerpc64-ibm-aix6.1.6.0
5c5
< Platform: powerpc-ibm-aix6.1.6.0
---
> Platform: powerpc64-ibm-aix6.1.6.0
9c9
< checking for gcc... gcc
---
> checking for gcc... xlc_r -qarch=pwr5 -qtune=pwr6 -q64
15,17c15,17
< checking whether we are using the GNU C compiler... yes
< checking whether gcc accepts -g... yes
< checking for gcc option to accept ANSI C... none needed
---
> checking whether we are using the GNU C compiler... no
> checking whether xlc_r -qarch=pwr5 -qtune=pwr6 -q64 accepts -g... yes
> checking for xlc_r -qarch=pwr5 -qtune=pwr6 -q64 option to accept ANSI C... none needed
19c19
< Applying APR hints file rules for powerpc-ibm-aix6.1.6.0
---
> Applying APR hints file rules for powerpc64-ibm-aix6.1.6.0
20a21,22
> setting AIX_XLC to "yes"
> adding "-qHALT=E" to CFLAGS
23d24
< setting LDFLAGS to "-Wl,-brtl"
25,26c26,27
< checking whether make sets $(MAKE)... yes
< checking how to run the C preprocessor... gcc -E
---
> checking whether gmake sets $(MAKE)... yes
> checking how to run the C preprocessor... xlc_r -qarch=pwr5 -qtune=pwr6 -q64 -E
56,59c57,60
< checking for ld used by gcc... /usr/bin/ld
< checking if the linker (/usr/bin/ld) is GNU ld... no
< checking for /usr/bin/ld option to reload object files... -r
< checking for BSD-compatible nm... /usr/ccs/bin/nm -B
---
> checking for non-GNU ld... /usr/ccs/bin/ld
> checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
> checking for /usr/ccs/bin/ld option to reload object files... -r
> checking for BSD-compatible nm... nm -B -X64
102c103
< checking command to parse /usr/ccs/bin/nm -B output from gcc object... ok
---
> checking command to parse nm -B -X64 output from xlc_r -qarch=pwr5 -qtune=pwr6 -q64 object... ok
107,111c108,111
< checking if gcc supports -fno-rtti -fno-exceptions... no
< checking for gcc option to produce PIC...
< checking if gcc static flag -static works... no
< checking if gcc supports -c -o file.o... yes
< checking whether the gcc linker (/usr/bin/ld) supports shared libraries... no
---
> checking for xlc_r -qarch=pwr5 -qtune=pwr6 -q64 option to produce PIC...
> checking if xlc_r -qarch=pwr5 -qtune=pwr6 -q64 static flag -bnso -bI:/lib/syscalls.exp works... no
> checking if xlc_r -qarch=pwr5 -qtune=pwr6 -q64 supports -c -o file.o... yes
> checking whether the xlc_r -qarch=pwr5 -qtune=pwr6 -q64 linker (xlc_r -qarch=pwr5 -qtune=pwr6 -q64) supports shared libraries... no
123,125c123,129
< checking whether the compiler provides atomic builtins... yes
< checking whether to enable -D_LARGEFILE64_SOURCE... yes
< adding "-D_LARGEFILE64_SOURCE" to CPPFLAGS
---
> checking whether the compiler provides atomic builtins... no
> checking if xlc_r -qarch=pwr5 -qtune=pwr6 -q64 -MM can create proper make dependencies... no
> checking if xlc_r -qarch=pwr5 -qtune=pwr6 -q64 -M can create proper make dependencies... no
> checking if xlc_r -qarch=pwr5 -qtune=pwr6 -q64 -E -MM can create proper make dependencies... no
> checking if xlc_r -qarch=pwr5 -qtune=pwr6 -q64 -E -M can create proper make dependencies... no
> checking if cpp -M can create proper make dependencies... yes
> checking whether to enable -D_LARGEFILE64_SOURCE... no
139,140c143
< checking for CFLAGS needed for pthreads... -pthread
< adding "-pthread" to CFLAGS
---
> checking for CFLAGS needed for pthreads... none
248c251,252
< checking size of void*... 4
---
> checking size of void*... 8
> sendfile support disabled to avoid system problem
449c453
< checking size of void*... (cached) 4
---
> checking size of void*... (cached) 8
455c459
< checking size of long... 4
---
> checking size of long... 8
463c467
< checking whether ssize_t and long are the same... yes
---
> checking whether ssize_t and long are the same... no
465,466c469,470
< checking whether size_t and unsigned long are the same... yes
< checking size of ssize_t... 4
---
> checking whether size_t and unsigned long are the same... no
> checking size of ssize_t... 8
468,478c472,477
< checking size of size_t... 4
< checking which format to use for apr_size_t... %lu
< checking size of off_t... 4
< checking for mmap64... yes
< checking for sendfile64... no
< checking for sendfilev64... no
< checking for readdir64_r... yes
< checking for mkstemp64... yes
< checking which type to use for apr_off_t... off64_t
< checking size of ino_t... 4
< configure: using unsigned long for ino_t
---
> checking size of size_t... 8
> checking which format to use for apr_size_t... %ld
> checking size of off_t... 8
> checking which type to use for apr_off_t... off_t
> checking size of ino_t... 8
> configure: using ino_t for ino_t
480c479
< checking size of struct iovec... 8
---
> checking size of struct iovec... 16
488c487
< checking for strtoll... yes
---
> checking for strtol... yes
608,612c607,611
< setting EXTRA_CPPFLAGS to "-U__STR__ -D_THREAD_SAFE -D_LARGEFILE64_SOURCE"
< restoring CFLAGS to ""
< setting EXTRA_CFLAGS to "-g -O2 -pthread"
< restoring LDFLAGS to ""
< setting EXTRA_LDFLAGS to "-Wl,-brtl"
---
> setting EXTRA_CPPFLAGS to "-U__STR__ -D_THREAD_SAFE"
> restoring CFLAGS to "-O2 -qmaxmem=32768 -g "
> setting EXTRA_CFLAGS to " -qHALT=E"
> restoring LDFLAGS to "-Wl,-brtl"
> setting EXTRA_LDFLAGS to ""
Some of the specific emits relating to threading and mutexes
commmon to both attempts;
Checking for Locking...
checking for semget... yes
checking for semctl... yes
checking for semop... yes
checking for semtimedop... yes
checking for flock... no
checking for semaphore.h... (cached) yes
checking for library containing sem_open... none required
checking for sem_close... yes
checking for sem_unlink... yes
checking for sem_post... yes
checking for sem_wait... yes
checking for sem_timedwait... yes
checking OS.h usability... no
checking OS.h presence... no
checking for OS.h... no
checking for create_sem... no
checking for acquire_sem... no
checking for acquire_sem_etc... no
checking for working sem_open... yes
checking for union semun in sys/sem.h... no
checking for LOCK_EX in sys/file.h... yes
checking for F_SETLK in fcntl.h... yes
checking for SEM_UNDO in sys/sem.h... yes
checking for POLLIN in poll.h sys/poll.h... yes
checking for PTHREAD_PROCESS_SHARED in pthread.h... yes
checking for pthread_mutex_timedlock... yes
checking for pthread_mutexattr_setpshared... yes
checking for working PROCESS_SHARED locks... yes
checking for robust cross-process mutex support... no
checking for pthread_condattr_setpshared... yes
decision on apr_lock implementation method... SysV IPC semget()
checking if fcntl returns EACCES when F_SETLK is already held... yes
checking if all interprocess locks affect threads... no
checking if POSIX sems affect threads in the same process... no
checking if SysV sems affect threads in the same process... yes
checking if fcntl locks affect threads in the same process... no
checking if flock locks affect threads in the same process... no
checking for entropy source... /dev/urandom
Test results, stderr first again;
52 1500-010: (W) WARNING in main: Infinite loop. Program may not stop.
19 1500-010: (W) WARNING in main: Infinite loop. Program may not stop.
Line 61: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 77: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 102: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 126: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 147: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 163: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 188: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 212: 0509-022 Cannot load module
/home/hudson/workspace/apr-1.6/test/.libs/libmod_test.so.
0509-026 System error: A file or directory in the path name
does not exist.
Line 349: LFS support a no-op in 64-bit builds
Line 584: pollcb interface not supported
Line 611: pollcb interface not supported
Line 637: pollcb interface not supported
Line 653: pollcb interface not supported
Line 836: pollcb interface not supported
Line 733: pollcb interface not supported
Line 206: default_timedlock() should time out => Connection timed out
Line 206: sysvsem_timedlock() should time out => Connection timed out
Line 206: default_timed_timedlock() should time out => Connection timed out
Line 116: Problem generating sockaddr (670008): Hostname and service
name not provided or found
Line 389: expected something other than <0>, but saw <0>
Line 433: Cannot test if connect completes synchronously
Line 84: TCP isn't corkable
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 2.
Stop.
Test results from 64-bit xlc AIX;
teststatus=0; progfailed=""; for prog in testlockperf
testmutexscope testall sendfile ; do if test "$prog" = 'sendfile';
then for mode in blocking nonblocking timeout; do ./$prog client
$mode startserver 127.0.0.1; status=$?; if test $status != 0; then
teststatus=$status; progfailed="$progfailed '$prog mode $mode'"; fi;
done; else ./$prog -v; status=$?; if test $status != 0; then
teststatus=$status; progfailed="$progfailed $prog"; fi; fi; done;
if test $teststatus != 0; then echo "Programs failed:$progfailed";
fi; exit $teststatus
APR Lock Performance Test
==============
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 1 threads OK
microseconds: 310018 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 1 threads OK
microseconds: 315272 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 1 threads OK
microseconds: 563044 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 1 threads OK
microseconds: 380313 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 2 threads OK
microseconds: 1897984 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 2 threads OK
microseconds: 822725 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 2 threads OK
microseconds: 831952 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 2 threads OK
microseconds: 1509737 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 3 threads OK
microseconds: 1440199 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 3 threads OK
microseconds: 2356049 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 3 threads OK
microseconds: 1959389 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 3 threads OK
microseconds: 6620914 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 4 threads OK
microseconds: 2393626 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 4 threads OK
microseconds: 3042968 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 4 threads OK
microseconds: 3907215 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 4 threads OK
microseconds: 19608376 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 5 threads OK
microseconds: 2717510 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 5 threads OK
microseconds: 4320005 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 5 threads OK
microseconds: 4512658 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 5 threads OK
microseconds: 30609930 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 6 threads OK
microseconds: 5001631 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 6 threads OK
microseconds: 3593701 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 6 threads OK
microseconds: 6252176 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 6 threads OK
microseconds: 41184920 usec
Trying proc mutexes with mechanism `default'...
mutex mechanism `default' is global in scope on this platform.
Trying global mutexes with mechanism `default'...
no problem encountered...
Trying proc mutexes with mechanism `sysvsem'...
mutex mechanism `sysvsem' is global in scope on this platform.
Trying global mutexes with mechanism `sysvsem'...
no problem encountered...
Trying proc mutexes with mechanism `posix'...
mutex mechanism `posix' is global in scope on this platform.
Trying global mutexes with mechanism `posix'...
no problem encountered...
Trying proc mutexes with mechanism `fcntl'...
mutex mechanism `fcntl' is *NOT* global in scope on this platform.
Trying global mutexes with mechanism `fcntl'...
no problem encountered...
Trying proc mutexes with mechanism `proc_pthread'...
mutex mechanism `proc_pthread' is global in scope on this platform.
Trying global mutexes with mechanism `proc_pthread'...
no problem encountered...
Trying proc mutexes with mechanism `default_timed'...
mutex mechanism `default_timed' is global in scope on this platform.
Trying global mutexes with mechanism `default_timed'...
no problem encountered...
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testescape : SUCCESS
testfile : SUCCESS
testfilecopy : SUCCESS
testfileinfo : SUCCESS
testflock : SUCCESS
testfmt : SUCCESS
testfnmatch : SUCCESS
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testcond : SUCCESS
testlfs : SUCCESS
testmmap : SUCCESS
testnames : SUCCESS
testoc : SUCCESS
testpath : SUCCESS
testpipe : SUCCESS
testpoll : SUCCESS
testpools : SUCCESS
testproc : SUCCESS
testprocmutex : FAILED 3 of 6
testrand : SUCCESS
testsleep : SUCCESS
testshm : SUCCESS
testsock : FAILED 2 of 16
testsockets : SUCCESS
testsockopt : SUCCESS
teststr : SUCCESS
teststrnatcmp : SUCCESS
testtable : SUCCESS
testtemp : SUCCESS
testthread : SUCCESS
testtime : SUCCESS
testud : SUCCESS
testuser : SUCCESS
testvsn : SUCCESS
testskiplist : SUCCESS
Failed Tests Total Fail Failed %
===================================================
testdso 9 8 88.89%
testprocmutex 6 3 50.00%
testsock 16 2 12.50%
The obvious question, what is new since 1.5.2? New tests,
for one, new misbehavior as well; the prior results from
a recent product build with APR 1.5.2;
teststatus=0; \
progfailed=""; \
for prog in testlockperf testmutexscope testall sendfile ; do \
if test "$prog" = 'sendfile'; then \
for mode in blocking nonblocking timeout; do \
./$prog client $mode startserver 127.0.0.1; \
status=$?; \
if test $status != 0; then \
teststatus=$status; \
progfailed="$progfailed '$prog mode $mode'"; \
fi; \
done; \
else \
./$prog -v; \
status=$?; \
if test $status != 0; then \
teststatus=$status; \
progfailed="$progfailed $prog"; \
fi; \
fi; \
done; \
if test $teststatus != 0; then \
echo "Programs failed:$progfailed"; \
fi; \
exit $teststatus
APR Lock Performance Test
==============
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 1 threads OK
microseconds: 231557 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 1 threads OK
microseconds: 236112 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 1 threads OK
microseconds: 439320 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 2 threads OK
microseconds: 649729 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 2 threads OK
microseconds: 794767 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 2 threads OK
microseconds: 1966800 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 3 threads OK
microseconds: 1954095 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 3 threads OK
microseconds: 1648285 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 3 threads OK
microseconds: 6853713 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 4 threads OK
microseconds: 2883942 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 4 threads OK
microseconds: 2447592 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 4 threads OK
microseconds: 20957603 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 5 threads OK
microseconds: 2871582 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 5 threads OK
microseconds: 3501802 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 5 threads OK
microseconds: 30135067 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (UNNESTED) OK
Starting 6 threads OK
microseconds: 3285807 usec
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (NESTED) OK
Starting 6 threads OK
microseconds: 3994937 usec
apr_thread_rwlock_t Tests
Initializing the apr_thread_rwlock_t OK
Starting 6 threads OK
microseconds: 41736873 usec
Trying proc mutexes with mechanism `default'...
Mutex mechanism `default' is global in scope on this platform.
Trying global mutexes with mechanism `default'...
no problems encountered...
Trying proc mutexes with mechanism `sysvsem'...
Mutex mechanism `sysvsem' is global in scope on this platform.
Trying global mutexes with mechanism `sysvsem'...
no problems encountered...
Trying proc mutexes with mechanism `posix'...
Mutex mechanism `posix' is global in scope on this platform.
Trying global mutexes with mechanism `posix'...
no problems encountered...
Trying proc mutexes with mechanism `fcntl'...
Mutex mechanism `fcntl' is not global in scope on this platform.
Trying global mutexes with mechanism `fcntl'...
no problems encountered...
Trying proc mutexes with mechanism `proc_pthread'...
Mutex mechanism `proc_pthread' is global in scope on this platform.
Trying global mutexes with mechanism `proc_pthread'...
no problems encountered...
testatomic : SUCCESS
testdir : SUCCESS
testdso : SUCCESS
testdup : SUCCESS
testenv : SUCCESS
testescape : SUCCESS
testfile : SUCCESS
testfilecopy : SUCCESS
testfileinfo : SUCCESS
testflock : SUCCESS
testfmt : SUCCESS
testfnmatch : SUCCESS
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testcond : SUCCESS
testlfs : Line 345: Large Files not supported
SUCCESS
testmmap : SUCCESS
testnames : SUCCESS
testoc : SUCCESS
testpath : SUCCESS
testpipe : SUCCESS
testpoll : Line 584: pollcb interface not supported
Line 611: pollcb interface not supported
Line 637: pollcb interface not supported
Line 653: pollcb interface not supported
Line 733: pollcb interface not supported
SUCCESS
testpools : SUCCESS
testproc : SUCCESS
testprocmutex : SUCCESS
testrand : SUCCESS
testsleep : SUCCESS
testshm : SUCCESS
testsock : Line 333: expected something other than <0>, but saw <0>
Line 377: Cannot test if connect completes synchronously
FAILED 1 of 10
testsockets : SUCCESS
testsockopt : Line 84: TCP isn't corkable
SUCCESS
teststr : SUCCESS
teststrnatcmp : SUCCESS
testtable : SUCCESS
testtemp : SUCCESS
testthread : SUCCESS
testtime : SUCCESS
testud : SUCCESS
testuser : SUCCESS
testvsn : SUCCESS
testskiplist : SUCCESS
Failed Tests Total Fail Failed %
===================================================
testsock 10 1 10.00%
This program won't work on this platform because there is no support
for sendfile().
This program won't work on this platform because there is no support
for sendfile().
This program won't work on this platform because there is no support
for sendfile().
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Wed, 2017-04-26 at 02:09 -0500, William A Rowe Jr wrote:
> On Thu, Apr 20, 2017 at 12:36 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> > Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks good,
> > at least, passes all tests, sysv sem timed locks discovered. Hopefully
> > able to test in the next day or few.
>
>
> With access restored, neither attempt is interesting/successful without
> hints. I'll apply my usual platform-specific tweaks in the morning and
> see if I get any more positive results, but am starting from a minimalist
> approach rather than my seal-clubbing old-school angle on odd platforms.
A minimalist approach is Good. But when you say minimalist, do you
mean minimalist efforts as in "this should work out-of-the-box"
or minimalist efforts as in a README.platform? Are we likely
looking at more code commits?
--
Nick Kew
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 20, 2017 at 12:36 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks good,
> at least, passes all tests, sysv sem timed locks discovered. Hopefully
> able to test in the next day or few.
With access restored, neither attempt is interesting/successful without
hints. I'll apply my usual platform-specific tweaks in the morning and
see if I get any more positive results, but am starting from a minimalist
approach rather than my seal-clubbing old-school angle on odd platforms.
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
> On 20 Apr 2017, at 18:36, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks good,
> at least, passes all tests, sysv sem timed locks discovered. Hopefully
> able to test
> in the next day or few.
Do your platforms look good to go? Any more issues we should tackle?
—
Nick Kew
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Couple issues tunneling into my AIX/HPUX boxes. ppc64 RHEL 5 linux looks good,
at least, passes all tests, sysv sem timed locks discovered. Hopefully
able to test
in the next day or few.
On Wed, Apr 19, 2017 at 1:43 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> With patches now accounted for I can pre-test and report back today on AIX,
> HPUX and propose a fix to silence the win32 32 -> 16 bit warnings (after
> division is done.)
>
> But my inclination is to defer this new feature to a later 1.7+2.0 release.
> Shipping a feature that devs would expect to need when it may be largely
> unavailable seems a disservice to our end users and these devs.
>
>
>
> On Apr 19, 2017 10:45, "Nick Kew" <ni...@apache.org> wrote:
>>
>> On Tue, 18 Apr 2017 00:16:37 +0200
>> Yann Ylavic <yl...@gmail.com> wrote:
>>
>> > > 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.
>> >
>> > Maybe we need to "#define APR_USE_PROC_PTHREAD_MUTEX_COND 0" for
>> > Solaris 10, and fall back to the generic implementation (spinning
>> > sleep)...
>>
>> I've just (r1791932) made timedlocks a config option on unix-family.
>> Defaults to on, but any users getting bitten by it can now use
>> --disable-timedlocks and the timedlock function return APR_ENOTIMPL
>> (as per earlier discussion, after being bitten by Mac but before
>> Solaris versions joined the awkward squad).
>>
>> Given that two mainstream platforms have bitten us on this in the
>> pre-release cycle, it would seem very high risk now to release
>> without such a workaround. We can request that anyone who finds
>> themselves having to use it report back to us!
>>
>> --
>> Nick Kew
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
With patches now accounted for I can pre-test and report back today on AIX,
HPUX and propose a fix to silence the win32 32 -> 16 bit warnings (after
division is done.)
But my inclination is to defer this new feature to a later 1.7+2.0 release.
Shipping a feature that devs would expect to need when it may be largely
unavailable seems a disservice to our end users and these devs.
On Apr 19, 2017 10:45, "Nick Kew" <ni...@apache.org> wrote:
> On Tue, 18 Apr 2017 00:16:37 +0200
> Yann Ylavic <yl...@gmail.com> wrote:
>
> > > 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.
> >
> > Maybe we need to "#define APR_USE_PROC_PTHREAD_MUTEX_COND 0" for
> > Solaris 10, and fall back to the generic implementation (spinning
> > sleep)...
>
> I've just (r1791932) made timedlocks a config option on unix-family.
> Defaults to on, but any users getting bitten by it can now use
> --disable-timedlocks and the timedlock function return APR_ENOTIMPL
> (as per earlier discussion, after being bitten by Mac but before
> Solaris versions joined the awkward squad).
>
> Given that two mainstream platforms have bitten us on this in the
> pre-release cycle, it would seem very high risk now to release
> without such a workaround. We can request that anyone who finds
> themselves having to use it report back to us!
>
> --
> Nick Kew
>
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Tue, 18 Apr 2017 00:16:37 +0200
Yann Ylavic <yl...@gmail.com> wrote:
> > 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.
>
> Maybe we need to "#define APR_USE_PROC_PTHREAD_MUTEX_COND 0" for
> Solaris 10, and fall back to the generic implementation (spinning
> sleep)...
I've just (r1791932) made timedlocks a config option on unix-family.
Defaults to on, but any users getting bitten by it can now use
--disable-timedlocks and the timedlock function return APR_ENOTIMPL
(as per earlier discussion, after being bitten by Mac but before
Solaris versions joined the awkward squad).
Given that two mainstream platforms have bitten us on this in the
pre-release cycle, it would seem very high risk now to release
without such a workaround. We can request that anyone who finds
themselves having to use it report back to us!
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@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
Re: 1.6.0 release candidates
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Apr 28, 2017 at 12:41 AM, Rainer Jung <ra...@kippdata.de> wrote:
> Am 25.04.2017 um 17:27 schrieb Yann Ylavic:
>>
>> On Tue, Apr 25, 2017 at 9:55 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>>
>>>
>>> The attached patch prevents this by looping on
>>> pthread_cond_[timed]wait() until the condition is satisfied.
>>> Would you please try it?
>>
>>
>> Committed to trunk (only) in r1792622, for easier/wider testing possibly.
>
>
> I applied r1792621, r1792622 and r1792625 and tested on Solaris 8 and 10.
> For the test I tried with and without "--enable-timedlocks". I also added
> the hard disabling of (the broken) pthread_mutex_timedlock on Solaris 10
> before testing.
>
> The tests do no longer hang.
Thanks for testing, so proc tests look good now right?
> The only strangeness is without
> "--enable-timedlocks" on Solaris 10 I get some "error" lines in the "APR
> Lock Performance Test" section (testlockperf.c) for the tests of type
> "(TIMED)":
>
> ...
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (TIMED) OK
> Starting 2 threads OK
> microseconds: 697841 usec
> error: counter = 1837161
> ...
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (TIMED) OK
> Starting 3 threads OK
> microseconds: 1194129 usec
> error: counter = 2562724
> ...
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (TIMED) OK
> Starting 4 threads OK
> microseconds: 1890774 usec
> error: counter = 3462599
> ...
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (TIMED) OK
> Starting 5 threads OK
> microseconds: 3713934 usec
> error: counter = 4897388
> ...
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (TIMED) OK
> Starting 6 threads OK
> microseconds: 2638046 usec
> error: counter = 4479066
> ...
>
> So these tests end too early. The counter should be 1000000*#threads, but it
> is always smaller.
>
> I do not see such "error" lines for Linux.
I did the same changes (as r1792622) for thread-mutex in r1794266,
better with it applied?
Thanks,
Yann.
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
Am 25.04.2017 um 17:27 schrieb Yann Ylavic:
> On Tue, Apr 25, 2017 at 9:55 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>> The attached patch prevents this by looping on
>> pthread_cond_[timed]wait() until the condition is satisfied.
>> Would you please try it?
>
> Committed to trunk (only) in r1792622, for easier/wider testing possibly.
I applied r1792621, r1792622 and r1792625 and tested on Solaris 8 and
10. For the test I tried with and without "--enable-timedlocks". I also
added the hard disabling of (the broken) pthread_mutex_timedlock on
Solaris 10 before testing.
The tests do no longer hang. The only strangeness is without
"--enable-timedlocks" on Solaris 10 I get some "error" lines in the "APR
Lock Performance Test" section (testlockperf.c) for the tests of type
"(TIMED)":
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 2 threads OK
microseconds: 697841 usec
error: counter = 1837161
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 3 threads OK
microseconds: 1194129 usec
error: counter = 2562724
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 4 threads OK
microseconds: 1890774 usec
error: counter = 3462599
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 5 threads OK
microseconds: 3713934 usec
error: counter = 4897388
...
apr_thread_mutex_t Tests
Initializing the apr_thread_mutex_t (TIMED) OK
Starting 6 threads OK
microseconds: 2638046 usec
error: counter = 4479066
...
So these tests end too early. The counter should be 1000000*#threads,
but it is always smaller.
I do not see such "error" lines for Linux.
Regards,
Rainer
Re: 1.6.0 release candidates
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Apr 25, 2017 at 9:55 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
> The attached patch prevents this by looping on
> pthread_cond_[timed]wait() until the condition is satisfied.
> Would you please try it?
Committed to trunk (only) in r1792622, for easier/wider testing possibly.
>
>
> Regards,
> Yann.
Re: 1.6.0 release candidates
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Rainer,
sorry for the delay.
On Wed, Apr 19, 2017 at 1:36 PM, Rainer Jung <ra...@kippdata.de> wrote:
>
> The wait_usec loop tying the apr_proc_mutex_timedlock() very often succeeds
> already during the first or second, sometimes the third attempt. But then
> the outer loop "while (i < MAX_ITER)" suddenly starts to fail because the
> inner loop switches behavior and apr_proc_mutex_timedlock() always gets the
> timeout until we stop trying due to wait_usec. Increasing MAX_WAIT_USEC from
> 1 sec to 5 sec didn't help. I have no idea, what the root cause for this
> behavior switching is.
I think what might happen is some pthread_cond_timedwait() spurious
wakeup (which I thought was avoided by counting the number of
waiters), or another possibility is a wakeup with timeout whereas the
cond is simultaneously signaled.
I both cases this could lead to a desynchronization between
proc_mutex_pthread_acquire_ex() and proc_mutex_pthread_release().
The attached patch prevents this by looping on
pthread_cond_[timed]wait() until the condition is satisfied.
Would you please try it?
Regards,
Yann.
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
Hello Yann,
Am 18.04.2017 um 23:37 schrieb Yann Ylavic:
> On Tue, Apr 18, 2017 at 4:25 PM, Rainer Jung <ra...@kippdata.de> wrote:
>> Am 18.04.2017 um 00:16 schrieb Yann Ylavic:
>>>
>>> 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,
>
> Do you really mean more unlocks than locks?
> I don't see how locks/unlocks could be unbalanced in
> proc_mutex_pthread_acquire_ex() and proc_mutex_pthread_release().
>
> For each the testprocmutex's child process loop, there should be a max
> of 2 locks+unlocks per proc_mutex_pthread_acquire_ex() (given that
> pthread_cond_timedwait() itself releases and re-acquires the mutex if
> it's called), and 1 lock+unlock per proc_mutex_pthread_release().
> That's something like 3 x CHILDREN x MAX_ITER = 3600 locks and as much
> unlocks for the whole "default_timed" test, if no timeout occurs!
> According to your numbers, that'd mean ~150 timeouts/retries on a
> total of 1200 loops (~12.5%).
>
>> and also about
>> 40.000 per thread of:
>>
>> lwp_cond_wait(0xFF040018, 0xFF040000, 0xFFBEF868) Err#62 ETIME
>
> So < 10% of the 2400 proc_mutex_pthread_acquire_ex()'s locks+unlocks
> come from pthread_cond_timedwait(), which means most of the
> apr_proc_mutex_timedlock() end up being simple {pthread_mutex_lock();
> locked=1; pthread_mutex_unlock()}, and sounds to me like a costly
> mutex implementation on Solaris 8...
>
>>
>> Any idea what to look for in the condvar impl of the timedlock feature?
>
> Since I wrote it I may be missing something, but I see nothing wrong yet...
> We could optimize it for the non contended case by using atomics on
> the shared proc_pthread_mutex_t->cond_locked state still.
>
> How is the following patch working, by waiting for a more or less
> longer time on the mutex in the test (here 10ms)?
>
> Index: test/testprocmutex.c
> ===================================================================
> --- test/testprocmutex.c (revision 1791728)
> +++ test/testprocmutex.c (working copy)
> @@ -87,11 +87,12 @@ static void make_child(abts_case *tc, int trylock,
> }
> else if (trylock < 0) {
> int wait_usec = 0;
> + apr_interval_time_t timeout = apr_time_from_msec(10);
>
> - while ((rv = apr_proc_mutex_timedlock(proc_lock, 1))) {
> + while ((rv = apr_proc_mutex_timedlock(proc_lock, timeout))) {
> if (!APR_STATUS_IS_TIMEUP(rv))
> exit(1);
> - if (++wait_usec >= MAX_WAIT_USEC)
> + if (++wait_usec >= MAX_WAIT_USEC / timeout)
> exit(1);
> }
> }
> _
>
Thanks for pointing me at that code. I tried a variation of timeouts.
The test on Solaris 10 nearly always fails here *after some time*.
The wait_usec loop tying the apr_proc_mutex_timedlock() very often
succeeds already during the first or second, sometimes the third
attempt. But then the outer loop "while (i < MAX_ITER)" suddenly starts
to fail because the inner loop switches behavior and
apr_proc_mutex_timedlock() always gets the timeout until we stop trying
due to wait_usec. Increasing MAX_WAIT_USEC from 1 sec to 5 sec didn't
help. I have no idea, what the root cause for this behavior switching is.
I also tried Solaris specific pthread_cond_reltimedwait_np() instead of
pthread_cond_timedwait() to rule out some time calculation problems and
deltas between clocks APR might use and the CLOCK that the system impl
uses. That didn't help though.
It also does not seem to be a problem with spurious wakeups or early
return from the timed waiting.
Regards,
Rainer
Re: 1.6.0 release candidates
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Apr 18, 2017 at 4:25 PM, Rainer Jung <ra...@kippdata.de> wrote:
> Am 18.04.2017 um 00:16 schrieb Yann Ylavic:
>>
>> 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,
Do you really mean more unlocks than locks?
I don't see how locks/unlocks could be unbalanced in
proc_mutex_pthread_acquire_ex() and proc_mutex_pthread_release().
For each the testprocmutex's child process loop, there should be a max
of 2 locks+unlocks per proc_mutex_pthread_acquire_ex() (given that
pthread_cond_timedwait() itself releases and re-acquires the mutex if
it's called), and 1 lock+unlock per proc_mutex_pthread_release().
That's something like 3 x CHILDREN x MAX_ITER = 3600 locks and as much
unlocks for the whole "default_timed" test, if no timeout occurs!
According to your numbers, that'd mean ~150 timeouts/retries on a
total of 1200 loops (~12.5%).
> and also about
> 40.000 per thread of:
>
> lwp_cond_wait(0xFF040018, 0xFF040000, 0xFFBEF868) Err#62 ETIME
So < 10% of the 2400 proc_mutex_pthread_acquire_ex()'s locks+unlocks
come from pthread_cond_timedwait(), which means most of the
apr_proc_mutex_timedlock() end up being simple {pthread_mutex_lock();
locked=1; pthread_mutex_unlock()}, and sounds to me like a costly
mutex implementation on Solaris 8...
>
> Any idea what to look for in the condvar impl of the timedlock feature?
Since I wrote it I may be missing something, but I see nothing wrong yet...
We could optimize it for the non contended case by using atomics on
the shared proc_pthread_mutex_t->cond_locked state still.
How is the following patch working, by waiting for a more or less
longer time on the mutex in the test (here 10ms)?
Index: test/testprocmutex.c
===================================================================
--- test/testprocmutex.c (revision 1791728)
+++ test/testprocmutex.c (working copy)
@@ -87,11 +87,12 @@ static void make_child(abts_case *tc, int trylock,
}
else if (trylock < 0) {
int wait_usec = 0;
+ apr_interval_time_t timeout = apr_time_from_msec(10);
- while ((rv = apr_proc_mutex_timedlock(proc_lock, 1))) {
+ while ((rv = apr_proc_mutex_timedlock(proc_lock, timeout))) {
if (!APR_STATUS_IS_TIMEUP(rv))
exit(1);
- if (++wait_usec >= MAX_WAIT_USEC)
+ if (++wait_usec >= MAX_WAIT_USEC / timeout)
exit(1);
}
}
_
Regards,
Yann.
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@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?
Regards,
Rainer
Re: 1.6.0 release candidates
Posted by Yann Ylavic <yl...@gmail.com>.
Thanks Rainer for the detailed report (as usual).
On Mon, Apr 17, 2017 at 2:01 PM, Rainer Jung <ra...@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.
>
> 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.
Maybe we need to "#define APR_USE_PROC_PTHREAD_MUTEX_COND 0" for
Solaris 10, and fall back to the generic implementation (spinning
sleep)...
Regards,
Yann.
Re: 1.6.0 release candidates
Posted by Branko Čibej <br...@apache.org>.
On 17.04.2017 14:01, Rainer Jung wrote:
> - ".svn" directory included, that's unusual
Always 'svn export' the tag, not 'svn checkout' ...
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
> On 17 Apr 2017, at 13:01, Rainer Jung <ra...@kippdata.de> wrote:
>
> c) Failure to compile apr on Solaris 8
> d) Hang during APR make check on Solaris 10 (testprocmutex)
Rainer, are these issues now fixed for you, with Yann’s fixes to the source and
my making timedlocks a config option now marked experimental?
—
Nick Kew
Re: 1.6.0 release candidates
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Apr 17, 2017 at 11:06 AM, Nick Kew <ni...@apache.org> wrote:
> On Mon, 2017-04-17 at 14:01 +0200, Rainer Jung wrote:
>
> Thanks for the comments.
>
>> 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
>
> Indeed. Do you think those should be encouraged, as they don't
> actually give any more security than a simple checksum?
IMO, MD5 (supported on any box) and SHA256 (supported only with
more modern distros) still make sense. No reason to add SHA1, the
MD5 is enough for non-deliberate integrity validation. SHA256 can
be enough if the fingerprint is from https://apr.apache.org/dist/apr/ but
isn't a recommended substitute for a valid .asc PGP validation.
>> - zip archives not named "win32-src.zip" as previously
See below
>> - CHANGES-APR-1.6 and CHANGES-APR-UTIL-1.6 missing
That could happen when you roll (I do this because I have the two
tarballs unpacked at the time), but can just as easily happen when
you are publishing the release. The contents are in the tarballs
for review already.
>> - HEADER.html and README.html missing
I see in http://apr.apache.org/dev/dist/
NOTICE: This file store contains only release candidates, not released
tarballs. These are only provided by the dev@apr.apache.org list's
Release Managers to consider release candidates prior to moving them
to their proper home http://www.apache.org/dist/apr/
so this is fine where we've traditionally posted the candidates - they
don't go in the tarball.
That URL corresponds to
https://dist.apache.org/repos/dist/dev/apr/
>> - Announcement1.6.txt and Announcement1.6.html missing
>
> AFAICS those don't feature in the tarballs? I looked at
> the 1.5.latest of APR/APU and I don't see them.
Typically we keep a copy of these in dev/dist/ for massaging the
release messages. They don't go in the tarball.
Typically we simply copy (or svn mv) the release and these extra
artifacts over from https://dist.apache.org/repos/dist/dev/apr/
to https://dist.apache.org/repos/dist/release/apr/ when it is time
to populate the mirrors.
>> - Key B87F79A9 missing from KEYS file
>
> Good point. Since ASF now auto-generates per-project keys files
> daily, why maintain a separate KEYS file?
>
>> - Key B87F79A9 is listed as "revoked: 2016-08-16" in key server
>
> I saw that key after uploading the tarballs!
> That key has a wrong creation date and wrong fingerprint:
> it's an imposter who created a clash (I recollect discussing
> that, though I only just found out that a fake with my name
> on it was "out there")! My real key is in
> http://people.apache.org/keys/group/apr.asc and
> http://people.apache.org/keys/committer/
> (along with my old 1024-bit key, which I can also use if this
> is creating confusion).
>
>> - ".svn" directory included, that's unusual
>> - STATUS file included, that's unusual
>
> It's a fair cop, guv!
>
>> - 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)
>
> Ah, right. Yep, that's probably not such a good idea.
Right - this is why they were named -win32-src.zip, to remind folks
that they can't find the unix tools, even if they were to switch the
lineends back to lf.
> Do we in fact still need those in the Unix tarballs? Are there
> platforms out there with the toolchain for configure/make but not
> for buildconf?
YES! The whole autocruft is very hard to get right on older solaris,
hpux, aix and other operating systems that just aren't Linux. Can't
comment on BSD compatibility of autocruft.
>> - no more bundled expat: we need to note that in the release notes
>
> Agreed, that was certainly on the agenda for the announcement.
+1 to include in Announcement (and probably on the site download
reference for the package). A pointer to the project would be good;
http://expat.sourceforge.net/ (soon to be github, but there isn't much
there yet.)
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Nick,
Am 17.04.2017 um 18:06 schrieb Nick Kew:
> On Mon, 2017-04-17 at 14:01 +0200, Rainer Jung wrote:
>
> Thanks for the comments.
>
>> 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
>
> Indeed. Do you think those should be encouraged, as they don't
> actually give any more security than a simple checksum?
I thought those are not for security but to easily detect transfer
errors. Only the pgp signature is for security. The hashes still seem to
be frequently provided.
>> - 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
>
> AFAICS those don't feature in the tarballs? I looked at
> the 1.5.latest of APR/APU and I don't see them.
Right, those files will not be part of the artefacts but exist in the
download directory, e.g.:
https://dist.apache.org/repos/dist/release/apr/
or
http://archive.apache.org/dist/apr/
>> - Key B87F79A9 missing from KEYS file
>
> Good point. Since ASF now auto-generates per-project keys files
> daily, why maintain a separate KEYS file?
Didn't know about that feature. Can it also be used to check historic
signatures, e.g. of old releases? At least we would have to rephrase
http://apr.apache.org/download.cgi
the KEYS file is mentioned there.
>> - Key B87F79A9 is listed as "revoked: 2016-08-16" in key server
>
> I saw that key after uploading the tarballs!
> That key has a wrong creation date and wrong fingerprint:
> it's an imposter who created a clash (I recollect discussing
> that, though I only just found out that a fake with my name
> on it was "out there")! My real key is in
> http://people.apache.org/keys/group/apr.asc and
> http://people.apache.org/keys/committer/
> (along with my old 1024-bit key, which I can also use if this
> is creating confusion).
Thanks for correcting this.
>> - ".svn" directory included, that's unusual
>> - STATUS file included, that's unusual
>
> It's a fair cop, guv!
>
>> - 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)
>
> Ah, right. Yep, that's probably not such a good idea.
>
> Do we in fact still need those in the Unix tarballs? Are there
> platforms out there with the toolchain for configure/make but not
> for buildconf?
I always thought about deleting the build/l*.m4 files coming from
libtool while running buildconf at the end of buildconf. I think they
are not needed for building and if you rerun buildoncf they will again
get copied from the libtool installation.
IMHO we should stick to configure/make as the normal build procedure and
not demand people to run buildconf. Users who build should not have a
need to care about libtool and auto tools installations. So I'd keep the
files generated by buildconf for the Unix tarballs (except for the
build/l*.m4 files as mentioned above).
>> - no more bundled expat: we need to note that in the release notes
>
> Agreed, that was certainly on the agenda for the announcement.
>
>
>> 2) Compile and run
>> ==================
>>
>> a) New apr configure options
>> b) Changes in apr-util configure options
>
> Useful for release notes :)
>
>> c) Failure to compile apr on Solaris 8
>> --------------------------------------
>
> Damn. That looks like a showstopper for release. But shouldn't
> be too hard, since you've tracked down the cause.
Yes I think that one should get fixed.
>> which indeed doesn't look like a good lvalue.
>
> Indeedie.
>
>> d) Hang during APR make check on Solaris 10 (testprocmutex)
>> -----------------------------------------------------------
>>
>> pthread_mutex_timedlock() hangs when the
>> current thread already has
>> locked the mutex.
>
> Hmmm, OK. We knew the timedlock stuff had potential to blow up.
> I guess that points back to the plan of making it a config option.
I'll try to dig some more info whether the problem can be fixed by an OS
patch for Solaris 10. At least it shows the potential for problems.
I'm a bit undecided on the config option, because that means we'll have
builds with subtle API differences. Most of the other APR config options
are not a good comparison for a consistent decision.
> I'm out this evening, but will hopefully find time tomorrow to
> revisit these problems. And I need to do some more digging
> around that bogus PGP key!
Thanks!
Rainer
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.04.2017 um 12:09 schrieb Nick Kew:
> On Mon, 2017-04-17 at 17:06 +0100, Nick Kew wrote:
>> And I need to do some more digging
>> around that bogus PGP key!
>
> OK, this follows a subject that's been raised @apache before:
> https://mail-search.apache.org/members/private-arch/members/201606.mbox/%3C1464999260.7490.275.camel@mimir.webthing.com%3E
> following which apache's own pages were fixed to stop using
> 32-bit key IDs.
>
> Underlying story is at https://evil32.com/ . I think I shall also
> blog this story and add my own thoughts.
Thank a bunch. So I had imported the wrong key resp. the right and the
wrong key by only using the short form of the fingerprint.
It turns out, that for my keys also invalid clones with the same short
fingerprint exist :(
I will be more careful in the future, using the full fingerprint.
Thanks again!
Rainer
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Mon, 2017-04-17 at 17:06 +0100, Nick Kew wrote:
> And I need to do some more digging
> around that bogus PGP key!
OK, this follows a subject that's been raised @apache before:
https://mail-search.apache.org/members/private-arch/members/201606.mbox/%3C1464999260.7490.275.camel@mimir.webthing.com%3E
following which apache's own pages were fixed to stop using
32-bit key IDs.
Underlying story is at https://evil32.com/ . I think I shall also
blog this story and add my own thoughts.
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Nick Kew <ni...@apache.org>.
On Mon, 2017-04-17 at 14:01 +0200, Rainer Jung wrote:
Thanks for the comments.
> 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
Indeed. Do you think those should be encouraged, as they don't
actually give any more security than a simple checksum?
> - 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
AFAICS those don't feature in the tarballs? I looked at
the 1.5.latest of APR/APU and I don't see them.
> - Key B87F79A9 missing from KEYS file
Good point. Since ASF now auto-generates per-project keys files
daily, why maintain a separate KEYS file?
> - Key B87F79A9 is listed as "revoked: 2016-08-16" in key server
I saw that key after uploading the tarballs!
That key has a wrong creation date and wrong fingerprint:
it's an imposter who created a clash (I recollect discussing
that, though I only just found out that a fake with my name
on it was "out there")! My real key is in
http://people.apache.org/keys/group/apr.asc and
http://people.apache.org/keys/committer/
(along with my old 1024-bit key, which I can also use if this
is creating confusion).
> - ".svn" directory included, that's unusual
> - STATUS file included, that's unusual
It's a fair cop, guv!
> - 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)
Ah, right. Yep, that's probably not such a good idea.
Do we in fact still need those in the Unix tarballs? Are there
platforms out there with the toolchain for configure/make but not
for buildconf?
> - no more bundled expat: we need to note that in the release notes
Agreed, that was certainly on the agenda for the announcement.
> 2) Compile and run
> ==================
>
> a) New apr configure options
> b) Changes in apr-util configure options
Useful for release notes :)
> c) Failure to compile apr on Solaris 8
> --------------------------------------
Damn. That looks like a showstopper for release. But shouldn't
be too hard, since you've tracked down the cause.
> which indeed doesn't look like a good lvalue.
Indeedie.
> d) Hang during APR make check on Solaris 10 (testprocmutex)
> -----------------------------------------------------------
>
> pthread_mutex_timedlock() hangs when the
> current thread already has
> locked the mutex.
Hmmm, OK. We knew the timedlock stuff had potential to blow up.
I guess that points back to the plan of making it a config option.
I'm out this evening, but will hopefully find time tomorrow to
revisit these problems. And I need to do some more digging
around that bogus PGP key!
--
Nick Kew
Re: 1.6.0 release candidates
Posted by Rainer Jung <ra...@kippdata.de>.
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