On 11/15/2007 10:26 PM, William A. Rowe, Jr. wrote:
> Please provide your input to release.
>
> [+1] APR-0.9.17
> [ ] APR-1.2.12
> [-1] APR-util-1.2.11
> [ ] APR-iconv-1.2.1
>
>
>
> I've already noticed I should have scuttled testreslist current
> implementation,
> but that's 20/20 hindsight and it sure isn't a showstopper.
>
These are my results so far (more tests to follow):
Signatures: All OK.
md5 sums: All OK.
APR 1.2.12 / APR-UTIL 1.2.11 tested with httpd testframework and httpd-2.2.6 on
Linux:
NO regressions.
Test results (make check):
APR 0.9.17:
Solaris 8 - 10, OpenSuSE 10.2: All OK.
So +1 from on APR 0.9.17.
APR 1.2.12:
Solaris 8 / 9: All OK except:
testshm : -Line 254: Error destroying shared memory block (22):
Invalid argument
FAILED 1 of 6
Failed Tests Total Fail Failed %
===================================================
testshm 6 1 16.67%
But as I have learned from previous posts this is expected and no regression.
Solaris 10: All OK except:
testpoll : /Line 314: expected <5>, but saw <4>
FAILED 1 of 13
testshm : -Line 254: Error destroying shared memory block (22):
Invalid argument
FAILED 1 of 6
Failed Tests Total Fail Failed %
===================================================
testpoll 13 1 7.69%
testshm 6 1 16.67%
Is the first one in testpoll expected? To be honest I did not do a regression
check
with APR 1.2.11 so far. So not vote from me on APR 1.2.12 currently as I also
need
to do Linux test.
APR-UTIL 1.2.11:
The testreslist test freezes because of a bug in apr_reslist_invalidate. The
following patch should
fix this, by activating the threads waiting for a resource:
--- apr_reslist.c.orig 2007-11-01 15:07:19.000000000 +0100
+++ apr_reslist.c 2007-11-16 14:52:35.789677000 +0100
@@ -370,6 +370,7 @@
apr_thread_mutex_lock(reslist->listlock);
ret = reslist->destructor(resource, reslist->params, reslist->pool);
reslist->ntotal--;
+ apr_thread_cond_signal(reslist->avail);
apr_thread_mutex_unlock(reslist->listlock);
return ret;
}
Comments? Otherwise I will commit tomorrow to trunk and 1.2.x
And testdate fails with
testdate : |Line 188: expected <Mon, 27 Feb 1995 20:49:44 GMT>, but
saw <Tue, 28 Feb 1995 04:49:44 GMT>
FAILED 1 of 2
Failed Tests Total Fail Failed %
===================================================
testdate 2 1 50.00%
IMHO one of these failures seems to be caused by a wrong testcase:
--- apr-util-1.2.11/test/testdate.c 2007-10-30 19:12:15.000000000 +0100
+++ apr-util-1.2.11.new/test/testdate.c 2007-11-16 17:30:48.593086000 +0100
@@ -32,7 +32,7 @@
{ "Monday, 27-Feb-95 20:49:44 -0800", "Tue, 28 Feb 1995 04:49:44 GMT" },
{ "Tue, 4 Mar 1997 12:43:52 +0200", "Tue, 04 Mar 1997 10:43:52 GMT" },
{ "Mon, 27 Feb 95 20:49:44 -0800", "Tue, 28 Feb 1995 04:49:44 GMT" },
- { "Tue, 4 Mar 97 12:43:52 +0200", "Tue, 04 Mar 1997 10:43:52 GMT" },
+ { "Tue, 4 Mar 97 12:43:52 +0200", "Tue, 04 Mar 1997 10:43:52 GMT" },
{ "Tue, 4 Mar 97 12:43:52 +0200", "Tue, 04 Mar 1997 10:43:52 GMT" },
{ "Mon, 27 Feb 95 20:49 GMT", "Mon, 27 Feb 1995 20:49:00 GMT" },
{ "Tue, 4 Mar 97 12:43 GMT", "Tue, 04 Mar 1997 12:43:00 GMT" },
and oddly enough the other testdate failures seem to be caused by bugs in
apr_date_parse_rfc
(which I cannot really believe for such a well tested function, so some remote
eyes please, or
some comments if the testcases are wrong and why. All failures are caused by
not respecting
the timezone string at the end of the test date). The following patch would fix
this:
--- apr-util-1.2.11/misc/apr_date.c 2007-11-01 15:07:19.000000000 +0100
+++ apr-util-1.2.11.new/misc/apr_date.c 2007-11-16 17:31:11.606303000 +0100
@@ -375,7 +375,7 @@
monstr = date + 3;
timstr = date + 10;
- gmtstr = date + 19;
+ gmtstr = date + 18;
TIMEPARSE_STD(ds, timstr);
}
@@ -412,7 +412,7 @@
monstr = date + 2;
timstr = date + 11;
- gmtstr = date + 20;
+ gmtstr = date + 19;
TIMEPARSE_STD(ds, timstr);
}
@@ -428,7 +428,7 @@
monstr = date + 3;
timstr = date + 10;
- gmtstr = date + 19;
+ gmtstr = date + 18;
TIMEPARSE_STD(ds, timstr);
}
@@ -444,7 +444,7 @@
monstr = date + 2;
timstr = date + 9;
- gmtstr = date + 18;
+ gmtstr = date + 17;
TIMEPARSE_STD(ds, timstr);
}
So -1 from me on APR-UTIL.
Regards
Rüdiger
