You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ruediger Pluem <rp...@apache.org> on 2020/06/19 12:08:18 UTC

s390x, ppc64le and arm64 Travis jobs always fail

Anyone an idea why the Travis builds on s390x, ppc64le and arm64 always fail
(e.g. https://travis-ci.org/github/apache/httpd/builds/700041805)? It looks like the server fails to start in time when running
the test suite.

Regards

RĂ¼diger

Re: s390x, ppc64le and arm64 Travis jobs always fail

Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jun 23, 2020 at 1:11 PM Joe Orton <jo...@redhat.com> wrote:
>
> On Tue, Jun 23, 2020 at 12:14:01PM +0200, Yann Ylavic wrote:
> > Argh, fixed in r1879110 (hopefully).
>
> Thanks a lot, looking green!  If we didn't find some actual bugs I would
> feel like burning thousands of hours of CPU time in CI was a wasted
> effort ;)

Thanks *you*! The CI is really awesome and reassuring.

Re: s390x, ppc64le and arm64 Travis jobs always fail

Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jun 23, 2020 at 12:14:01PM +0200, Yann Ylavic wrote:
> Argh, fixed in r1879110 (hopefully).

Thanks a lot, looking green!  If we didn't find some actual bugs I would 
feel like burning thousands of hours of CPU time in CI was a wasted 
effort ;)




Re: s390x, ppc64le and arm64 Travis jobs always fail

Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Jun 23, 2020 at 12:06 PM Joe Orton <jo...@redhat.com> wrote:
>
> On Tue, Jun 23, 2020 at 10:53:13AM +0100, Joe Orton wrote:
> > On Fri, Jun 19, 2020 at 02:21:48PM +0100, Joe Orton wrote:
> > > so if Apache-Test is trying to connect to ::1 but httpd is only
> > > listening on AF_INET port 80, it will look like the server is not
> > > running, even if it is.
> >
> > After r1879103 they are now at least starting up, but failing in the
> > proxy tests, which I find a bit surprising:
> >
> > https://travis-ci.org/github/apache/httpd/jobs/701189909
> >
> > # Failed test 3 in t/modules/proxy.t at line 22
> > # Failed test 4 in t/modules/proxy.t at line 23
> > t/modules/proxy.t ...................
> > Failed 2/31 subtests
> >
> > that seems to be failing in the <Location>-context ProxyPass test
> > *only*.
>
> cc Yann, I'm guessing this is an unsigned-char bug introduced in:
>
> http://svn.apache.org/viewvc?view=revision&revision=1879094
>
> these tests are going to default to *true* not *false* for unsigned char
> architectures:
>
> -        if (!dconf->mapping_decoded
> +        if (dconf->use_original_uri > 0

Argh, fixed in r1879110 (hopefully).

Re: s390x, ppc64le and arm64 Travis jobs always fail

Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jun 23, 2020 at 10:53:13AM +0100, Joe Orton wrote:
> On Fri, Jun 19, 2020 at 02:21:48PM +0100, Joe Orton wrote:
> > so if Apache-Test is trying to connect to ::1 but httpd is only 
> > listening on AF_INET port 80, it will look like the server is not 
> > running, even if it is.
> 
> After r1879103 they are now at least starting up, but failing in the 
> proxy tests, which I find a bit surprising:
> 
> https://travis-ci.org/github/apache/httpd/jobs/701189909
> 
> # Failed test 3 in t/modules/proxy.t at line 22
> # Failed test 4 in t/modules/proxy.t at line 23
> t/modules/proxy.t ................... 
> Failed 2/31 subtests 
> 
> that seems to be failing in the <Location>-context ProxyPass test 
> *only*.

cc Yann, I'm guessing this is an unsigned-char bug introduced in:

http://svn.apache.org/viewvc?view=revision&revision=1879094

these tests are going to default to *true* not *false* for unsigned char 
architectures:

-        if (!dconf->mapping_decoded
+        if (dconf->use_original_uri > 0



Re: s390x, ppc64le and arm64 Travis jobs always fail

Posted by Joe Orton <jo...@redhat.com>.
On Fri, Jun 19, 2020 at 02:21:48PM +0100, Joe Orton wrote:
> so if Apache-Test is trying to connect to ::1 but httpd is only 
> listening on AF_INET port 80, it will look like the server is not 
> running, even if it is.

After r1879103 they are now at least starting up, but failing in the 
proxy tests, which I find a bit surprising:

https://travis-ci.org/github/apache/httpd/jobs/701189909

# Failed test 3 in t/modules/proxy.t at line 22
# Failed test 4 in t/modules/proxy.t at line 23
t/modules/proxy.t ................... 
Failed 2/31 subtests 

that seems to be failing in the <Location>-context ProxyPass test 
*only*.

Not at all impossible this is still some IPv6 vs localhost vs 
getaddrinfo-related fubar but I can't see why that would cause the 
<Location>-specific tests to fail when the other tests are apparently 
working.  Any ideas?



Re: s390x, ppc64le and arm64 Travis jobs always fail

Posted by Joe Orton <jo...@redhat.com>.
On Fri, Jun 19, 2020 at 02:08:18PM +0200, Ruediger Pluem wrote:
> Anyone an idea why the Travis builds on s390x, ppc64le and arm64 always fail
> (e.g. https://travis-ci.org/github/apache/httpd/builds/700041805)? It looks like the server fails to start in time when running
> the test suite.

My guess:

The test config in the test framework use

Listen 0.0.0.0:<port>

throughout... that is hard-coded in Apache::Test IIRC

but if you look at the Apache::Test output in those failing jobs, it 
always looks like this:

https://travis-ci.org/github/apache/httpd/jobs/700041828#L2397

server ip6-localhost:8529 started
server ip6-localhost:8530 listening (mod_nntp_like)

which implies it thinks localhost is ::1

so if Apache-Test is trying to connect to ::1 but httpd is only 
listening on AF_INET port 80, it will look like the server is not 
running, even if it is.


Re: s390x, ppc64le and arm64 Travis jobs always fail

Posted by Eric Covener <co...@gmail.com>.
On Fri, Jun 19, 2020 at 8:08 AM Ruediger Pluem <rp...@apache.org> wrote:
>
> Anyone an idea why the Travis builds on s390x, ppc64le and arm64 always fail
> (e.g. https://travis-ci.org/github/apache/httpd/builds/700041805)? It looks like the server fails to start in time when running
> the test suite.

My half-court-shot guess would be RNG hang. I didn't look at the
travis script, but could we get pstack output of httpd processes when
it times out?