bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Darshit Shah
Subject: Re: [Bug-wget] [PATCH] Using parallel test harness
Date: Wed, 1 Oct 2014 17:39:37 +0530
User-agent: Mutt/1.5.23 (2014-03-12)

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.
The Test-iri* files fail when executed from the tests/ directory even
without the patch, but the issue with Test-proxied-https is definitely a
regression

Yes.

Tim


--- end quoted text ---

--
Thanking You,
Darshit Shah

Attachment: pgp8ep4mgt9J0.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]