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

[Tim Ruehsen]

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...

Tim

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