apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: [Votes] Apr candidates in /dev/dist/
Date Fri, 16 Nov 2007 02:18:58 GMT
On Nov 16, 2007 1:19 AM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> > On Nov 15, 2007 11:26 PM, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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
> >
> > gringo@lethe:~/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

Mime
View raw message