On Nov 16, 2007 1:19 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Lucian Adrian Grijincu wrote:
> > On Nov 15, 2007 11:26 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> >> Please provide your input to release.
> > Ubuntu 7.10 kernel 2.6.22-14, x86
> >
> > Details:
> >
> >> [-1] APR-1.2.12
> > on the first run:
> > testshm : FAILED 1 of 6
>
> Correct; this is not a regression, not a showstopper, but a new illustration
> of an existing bug. We may remove the shm backing store, and destroy the shm
> object (or let it clean up) but it will attempt to re-remove itself. It's
> illustrating the bug, no patch was forthcoming, I'm considering it closed
> until
> the next go-around with release 1.2.13.
>
the test goes like this
rv = apr_shm_remove(SHARED_FILENAME, p);
|
---> apr_file_remove(filename);
[...]
rv = apr_shm_destroy(shm);
|
---> return apr_file_remove(filename);
APR_ASSERT_SUCCESS(tc, "Error destroying shared memory block", rv);
To me it's obvious that the testcase should check for APR_ENOENT AND
APR_SUCCESS. (some platforms just return APR_ENOTIMPL for
apr_shm_remove and afterwards apr_shm_destroy will return APR_SUCCESS
in that case. This is not a bug in APR it's a bug in the testcase.)
Attached a patch for the testcases.
> > testsock : //bin/bash: line 1: 23623 Segmentation fault
> > (core dumped) ./$prog
>
> Yuck - have a backtrace of the core? This is usually indicative of strange
> configurations of the IP stack, win32 used to be notorious for such things.
>
Unfortunately no, I forgot to "ulimit -c unlimited" before running the
tests and there's no core dump.
I'll script it to run for some time, maybe I'll get lucky.
> > afterwards only the first error ON EVERY RUN; testsock seemed fine, I
> > can only hope it core dumped because of the test that failed before.
>
> Not for the shm test; but it sounds like we failed to check the rc of some
> specific test.
>
> >> [+1] APR-0.9.17
> > Not a showstopper from my POV:
> > starting consumer.....
> > Name-based shared memory test FAILED: [2] No such file or directory
> > starting producer.....
> > Name-based shared memory test FAILED: [2] No such file or directory
>
> No - those are fine, no regression.
>
> >> [-1] APR-util-1.2.11
> >
> > [EMAIL PROTECTED]:~/aprtest/apr-util-1.2.11$ ./test/testall -v
> > 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
>
> I /believe/ this is a failure in the test.
They are failing because the comparisons can't be right: this is from the tests.
static struct datetest {
const char *input;
const char *output;
} tests[] = {
{ "Mon, 27 Feb 1995 20:49:44 -0800", "Tue, 28 Feb 1995 04:49:44 GMT" },
....
}
...
date = apr_date_parse_rfc(tests[i].input);
apr_rfc822_date(str_date, date);
ABTS_STR_EQUAL(tc, str_date, tests[i].output);
I see no pattern in the strings defined at the start of the testfile,
but it's definitely a test bug.
>
> > testxml : |Line 68: expected <2>, but saw <0>
> > FAILED 1 of 1
>
> Ick - which expat?
>
> > testxlate : SUCCESS
> > testrmm : SUCCESS
> > testdbm : |Line 175: expected <2>, but saw <0>
> > FAILED 1 of 1
>
> Ick, which db?
#define APU_HAVE_SDBM 1
#define APU_HAVE_GDBM 0
#define APU_HAVE_NDBM 0
#define APU_HAVE_DB 0
Havent' been able to reproduce it, I hate this kinds of bugs.
The reason might be that I had CTRL+C-ed a previous run of ./testall
because of a dead testreslist and stuff may have not been cleaned up.
>
> > testqueue : SUCCESS
> > testreslist : \-|/-|\-|/-|\-|/-|\-|/-|\/ [[ and
> > deadlocks here forever (>3 min == infinity) ]]
>
> Reslist is broke, I did mention this in my post. I'd possibly consider
> rerolling tomorrow afternoon if someone wants to fix this test (not it's
> original implementation on 1.2 either - that was equally horrid).
>
> I'd also entertain rerolling after removing testreslist from the list of
> tests, altogether.
Without reslist only the badly written testdate still fails:
teststrmatch : SUCCESS
testuri : SUCCESS
testuuid : SUCCESS
testbuckets : SUCCESS
testpass : SUCCESS
testmd4 : SUCCESS
testmd5 : SUCCESS
testdbd : SUCCESS
testdate : FAILED 1 of 2
testxml : SUCCESS
testxlate : SUCCESS
testrmm : SUCCESS
testdbm : SUCCESS
testqueue : SUCCESS
Failed Tests Total Fail Failed %
===================================================
testdate 2 1 50.00%
--
Lucian
--- testshm.c 2007-11-16 03:25:29.000000000 +0200
+++ /home/gringo/apr12x/test/testshm.c 2007-11-06 11:01:41.000000000 +0200
@@ -251,7 +251,7 @@
}
rv = apr_shm_destroy(shm);
- ABTS_ASSERT(tc, "Error destroying shared memory block", rv == APR_SUCCESS || rv == APR_ENOENT);
+ APR_ASSERT_SUCCESS(tc, "Error destroying shared memory block", rv);
/* Now ensure no named resource remains which we may attach to */
rv = apr_shm_attach(&shm, SHARED_FILENAME, p);
