You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dan Poirier <po...@pobox.com> on 2010/07/22 16:20:44 UTC
2.2.16 RC - pr17629.t failure on Linux
Relatively new test pr17629.t seems to be failing for me on Linux:
# expected: begin-foobar-end
# received: !!!ERROR!!!
not ok 4
# Failed test 4 in t/apache/pr17629.t at line 47
Failed 1/4 subtests
In the error log:
[Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(48): [client 127.0.0.1] [mod_echo_post] going to echo 37 bytes
[Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(63): [client 127.0.0.1] [mod_echo_post] ap_get_client_block got error
[Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(67): [client 127.0.0.1] [mod_echo_post] done reading 0 bytes, 37 bytes remain
ap_get_client_block doesn't provide any more detail on why it fails.
Just me? Any suggestions on further debugging?
Thanks,
Dan
Re: 2.2.16 RC - pr17629.t failure on Linux
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jul 22, 2010 at 04:50:42PM +0200, "Plüm, Rüdiger, VF-Group" wrote:
> > What about these?
> >
> > t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
> >
> > Failed test: 2
> >
> > t/ssl/require.t (Wstat: 0 Tests: 8 Failed: 1)
> >
> > Failed test: 7
> >
> > I don't see any SSL-related proposed backports in STATUS that could
> > explain these.
>
> I see these as well. They don't happen on trunk, but they happen with 2.2.15
> as well, so it does not seem to be a regression. Nevertheless I do not
> understand why they happen at all.
These are testing for the bug fixed in r946240 (and should pass on the
trunk), though backporting that to 2.2.x is slightly more involved.
joe
RE: 2.2.16 RC - pr17629.t failure on Linux
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Dan Poirier [
> Sent: Donnerstag, 22. Juli 2010 16:45
> To: dev@httpd.apache.org
> Subject: Re: 2.2.16 RC - pr17629.t failure on Linux
>
> On 2010-07-22 at 10:32, "Plüm, Rüdiger, VF-Group"
> <ru...@vodafone.com> wrote:
>
> >> -----Original Message-----
> >> From: Dan Poirier
> >> Sent: Donnerstag, 22. Juli 2010 16:21
> >> To: dev@httpd.apache.org
> >> Subject: 2.2.16 RC - pr17629.t failure on Linux
> >>
> > This is no regression but due to a backport that missed the boat
> > for 2.2.16. See the STATUS file of 2.2.x and search for 17629.
>
> That would explain pr43939.t also, thanks.
>
> What about these?
>
> t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
>
> Failed test: 2
>
> t/ssl/require.t (Wstat: 0 Tests: 8 Failed: 1)
>
> Failed test: 7
>
> I don't see any SSL-related proposed backports in STATUS that could
> explain these.
I see these as well. They don't happen on trunk, but they happen with 2.2.15
as well, so it does not seem to be a regression. Nevertheless I do not
understand why they happen at all.
Regards
Rüdiger
Re: 2.2.16 RC - pr17629.t failure on Linux
Posted by Dan Poirier <po...@pobox.com>.
On 2010-07-22 at 10:32, "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com> wrote:
>> -----Original Message-----
>> From: Dan Poirier [mailto:poirier@pobox.com]
>> Sent: Donnerstag, 22. Juli 2010 16:21
>> To: dev@httpd.apache.org
>> Subject: 2.2.16 RC - pr17629.t failure on Linux
>>
> This is no regression but due to a backport that missed the boat
> for 2.2.16. See the STATUS file of 2.2.x and search for 17629.
That would explain pr43939.t also, thanks.
What about these?
t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1)
Failed test: 2
t/ssl/require.t (Wstat: 0 Tests: 8 Failed: 1)
Failed test: 7
I don't see any SSL-related proposed backports in STATUS that could
explain these.
Dan
RE: 2.2.16 RC - pr17629.t failure on Linux
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Dan Poirier [mailto:poirier@pobox.com]
> Sent: Donnerstag, 22. Juli 2010 16:21
> To: dev@httpd.apache.org
> Subject: 2.2.16 RC - pr17629.t failure on Linux
>
> Relatively new test pr17629.t seems to be failing for me on Linux:
>
> # expected: begin-foobar-end
> # received: !!!ERROR!!!
> not ok 4
> # Failed test 4 in t/apache/pr17629.t at line 47
> Failed 1/4 subtests
>
>
> In the error log:
>
> [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(48):
> [client 127.0.0.1] [mod_echo_post] going to echo 37 bytes
>
> [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(63):
> [client 127.0.0.1] [mod_echo_post] ap_get_client_block got
> error
> [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(67):
> [client 127.0.0.1] [mod_echo_post] done reading 0 bytes, 37
> bytes remain
>
> ap_get_client_block doesn't provide any more detail on why it fails.
>
> Just me? Any suggestions on further debugging?
This is no regression but due to a backport that missed the boat
for 2.2.16. See the STATUS file of 2.2.x and search for 17629.
Regards
Rüdiger