Mailing List Archive

On Fri, Jun 19, 2020 at 8:08 AM Ruediger Pluem <rpluem@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?

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.

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?

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

On Tue, Jun 23, 2020 at 12:06 PM Joe Orton <jorton@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).

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 ;)

On Tue, Jun 23, 2020 at 1:11 PM Joe Orton <jorton@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.