You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@covalent.net> on 2002/03/07 01:17:58 UTC
httpd-test + cvs head
to those working on filters, please make sure httpd-test/perl-framework
tests are passing. i'm seeing a bunch fail at the moment, a couple with
"response had protocol HTTP/0.9 (headers not sent?)" and various
segvs:
filter/case, filter/input_body:
Program received signal SIGSEGV, Segmentation fault.
0x08073f04 in add_any_filter_handle (frec=0x8167130, ctx=0x0, r=0x81f6c90,
c=0x0, r_filters=0x81f6e00, p_filters=0x81f6e08, c_filters=0x40)
at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:345
345 if (*r_filters != *c_filters) {
(gdb) p *r_filters
$1 = (ap_filter_t *) 0x81ae6b8
(gdb) p *c_filters
Cannot access memory at address 0x40
protocol/echo, protocol/nntp-like, any ssl request:
#0 0x08073fde in add_any_filter_handle (frec=0x80a2cf0, ctx=0x81b7370,
r=0x0,
c=0x81ae050, r_filters=0x0, p_filters=0x0, c_filters=0x81ae08c)
at /home/dougm/apache/farm/src/httpd-2.0-cvs/server/util_filter.c:368
368 if (fscan->next->prev == fscan) {
(gdb) p fscan
$1 = (ap_filter_t *) 0x81b7328
(gdb) p fscan->next
$2 = (ap_filter_t *) 0x0
RE: httpd-test + cvs head
Posted by Ryan Bloom <rb...@covalent.net>.
> On Wed, Mar 06, 2002 at 04:17:58PM -0800, Doug MacEachern wrote:
> > to those working on filters, please make sure
httpd-test/perl-framework
> > tests are passing. i'm seeing a bunch fail at the moment, a couple
with
> > "response had protocol HTTP/0.9 (headers not sent?)" and various
> > segvs:
>
> I think I've fixed most of these (by either committing fixes to
> httpd-test or to httpd-2.0). All of the tests except for mod_ssl
> are now passing for me.
>
> Failed Test Status Wstat Total Fail Failed List of Failed
> ---------------------------------------------------------------------
> ssl/http.t 1 1 100.00% 1
> ssl/varlookup.t 72 2 2.78% 39, 49
>
> However, mod_ssl is bogus. The ssl/http.t test is interesting
> since it causes mod_ssl to remove itself via
> ap_remove_output_filter() (mod_ssl.c:358). Since mod_ssl is a
> connection filter, our new strategy is that it can never be
> removed. Ooops. Since it doesn't have access to the request_rec,
HUH? Where did you get that connection filters can never be removed.
That was never said anywhere. You must be able to remove any filter.
> it can't destroy its predecessor's reference to itself. Perhaps
> this means we *do* need the ->prev.
Damn, that is a sticky wicket. My thought right now is that
ap_pass_brigade and ap_get_brigade automatically add the request_rec
pointer to the filter structure when they are called.
> We'll end up reading the fake request line, but the SSL input
> filter will still be present - since it is still referred to by
> r->output_filters. This will cause a segfault or other
> nastiness. I'm not aware how rbb wants to fix this, so I'll
> let him sort this out.
Ryan
Re: httpd-test + cvs head
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Mar 06, 2002 at 04:17:58PM -0800, Doug MacEachern wrote:
> to those working on filters, please make sure httpd-test/perl-framework
> tests are passing. i'm seeing a bunch fail at the moment, a couple with
> "response had protocol HTTP/0.9 (headers not sent?)" and various
> segvs:
I think I've fixed most of these (by either committing fixes to
httpd-test or to httpd-2.0). All of the tests except for mod_ssl
are now passing for me.
Failed Test Status Wstat Total Fail Failed List of Failed
---------------------------------------------------------------------
ssl/http.t 1 1 100.00% 1
ssl/varlookup.t 72 2 2.78% 39, 49
However, mod_ssl is bogus. The ssl/http.t test is interesting
since it causes mod_ssl to remove itself via
ap_remove_output_filter() (mod_ssl.c:358). Since mod_ssl is a
connection filter, our new strategy is that it can never be
removed. Ooops. Since it doesn't have access to the request_rec,
it can't destroy its predecessor's reference to itself. Perhaps
this means we *do* need the ->prev.
We'll end up reading the fake request line, but the SSL input
filter will still be present - since it is still referred to by
r->output_filters. This will cause a segfault or other
nastiness. I'm not aware how rbb wants to fix this, so I'll
let him sort this out.
I think tests 39, 49 failures are due to some certificate
problems - the regex doesn't seem to match. Doesn't look like
a filter problem. -- justin