Re: [Bug-wget] [PATCH] Using parallel test harness

[Tim Ruehsen]

On Wednesday 01 October 2014 15:02:52 Tim Ruehsen wrote:
> On Wednesday 01 October 2014 17:39:37 Darshit Shah wrote:
> > Answering in-line
> >
> > On 10/01, Tim Rühsen wrote:
> > >On Wednesday 01 October 2014 15:48:21 Darshit Shah wrote:
> > >> Test-proxied-https.px runs perfectly when executed directly but will
> > >> *always* fail when executed through make check.
> > >
> > >Maybe not always. "make check -j4" works here without failure, BUT Wget
> > >has
> > >to try twice (can be seen in the logs) - which is not how it should be. I
> > >did not see this before the rebase/top_srcdir->srcdir change.
> > >
> > >I'll investigate this after lunch.
> >
> > Okay, not always. Right now, it worked for me straight out of the box.
> > This
> > behavior only adds more credence to my claim that there's a race condition
> > in the test suite that is affecting the results.
> >
> > The original log file I sent shows how the test suite takes an exit code
> > of
> > 256 but there's nothing that supports such an exit from Wget's own output.
> >
> > >> The print statement at line 18 in Test-proxied-https.px complains about
> > >> an
> > >> uninitialized variable when the test is executed directly.
> > >
> > >Just one question: are you talking about Test-proxied-https-auth.px ?
> > >Because there is no Test-proxied-https.px here... uah, I forgot to remove
> > >a debugging print line (line 18). I'll fix that after lunch.
> >
> > Yes, I meant Test-proxied-https-auth.px.
> >
> > >> The Test-iri* tests all fail, *always", when either executed directly
> > >> or
> > >> when make check is called from the tests/ directory. They execute
> > >> successfully when make check is invoked from the root directory of the
> > >> repository. Hence, I believe the issue lies in the test suite and not
> > >> in
> > >> Wget.
> > >
> > >You are right. 'make check' from the root dir runs Wget with LC_ALL=C
> > >while
> > >the other two variants use your current locale settings. There is an
> > >issue
> > >in Wget or the tests itself - that has to be investigated.
> >
> > I'll try to write the tests in the Python based tests. That should give as
> > an answer as to where the problem lies.
>
> One problem seems starting the test server... of course the perl test suite
> has to wait until the server is ready... right now, it looks like this does
> not happen. So sometimes, Wget fails for the first time and retries.
>
> You should be able to reproduce with
> $ make check -j4
> $ grep -i retry tests/*.log
>
> Try this several times and you'll see different outputs from grep.
>
> An example (tests/Test-cookies-401.log):
> Running test Test-cookies-401
> Calling ../src/wget http://localhost:43447/one.txt
> http://localhost:43447/two.txt
> --2014-10-01 14:55:25--  http://localhost:43447/one.txt
> Resolving localhost (localhost)... 127.0.0.1
> Connecting to localhost (localhost)|127.0.0.1|:43447... connected.
> HTTP request sent, awaiting response... 401 Forbidden
>
> Username/Password Authentication Failed.
> --2014-10-01 14:55:25--  http://localhost:43447/two.txt
> Reusing existing connection to localhost:43447.
> HTTP request sent, awaiting response... Read error (Connection reset by
> peer) in headers.
> Retrying.
>
> --2014-10-01 14:55:26--  (try: 2)  http://localhost:43447/two.txt
> Connecting to localhost (localhost)|127.0.0.1|:43447... connected.
> HTTP request sent, awaiting response... 200 Ok
> Length: 12
> Saving to: 'two.txt'
>
>      0K                                                       100% 2.23M=0s
>
> 2014-10-01 14:55:26 (2.23 MB/s) - 'two.txt' saved [12/12]
>
> FINISHED --2014-10-01 14:55:26--
> Total wall clock time: 1.0s
> Downloaded: 1 files, 12 in 0s (2.23 MB/s)
> Test successful.
>
>
> This really looks like race - the parallel test suite just enforces the race
> to come out more often (as you already mentioned in a previous post).
>
> I'll come back later with more information...

The perl HTTP server seems to be ok - it has a child/parent sync mechanism
which looks good to me.

While there might be more than one problem, at least one is the naming of the
tests. The name given to HTTPServer->new() should always be unique because is
is taken as a temporary working directory. Some tests have wrong name
(copy&paste I guess) and thus randomly fail when running in parallel !

Here is a patch to fix this.

Tim

0001-fixed-test-suite-race-conditions-due-to-double-usage.patch
Description: Text Data

signature.asc
Description: This is a digitally signed message part.