You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@light.plus.com> on 2000/12/21 23:25:06 UTC
mod_dav unstable in 2.0
I'm getting lots of crashes with mod_dav in 2.0... I can reliably
reproduce this by doing 'open www, cat ., ls' in cadaver, so the full
stream of requests which go down the (single) connection are:
OPTIONS /, PROPFIND /, GET /, PROPFIND /
Here's the backtrace:
#0 0x401b0c28 in main_arena () from /lib/libc.so.6
#1 0x807f2cb in ap_http_filter (f=0x814333c, b=0x81457dc,
mode=AP_MODE_BLOCKING) at http_protocol.c:1008
#2 0x80a6102 in ap_get_brigade (next=0x814333c, bb=0x81457dc,
mode=AP_MODE_BLOCKING) at util_filter.c:215
#3 0x8082cc6 in ap_get_client_block (r=0x81450bc,
buffer=0x8145eec "Thu, 21 Dec 2000 21:16:46 GMT", bufsiz=2048)
at http_protocol.c:2857
#4 0x80a4c33 in ap_xml_parse_input (r=0x81450bc, pdoc=0xbffff3bc)
at util_xml.c:411
#5 0x80629ef in dav_method_propfind (r=0x81450bc) at mod_dav.c:1547
#6 0x8066bd6 in dav_handler (r=0x81450bc) at mod_dav.c:3866
#7 0x80966f9 in ap_invoke_handler (r=0x81450bc) at config.c:364
#8 0x80870a9 in process_request_internal (r=0x81450bc) at
http_request.c:1348
#9 0x8087181 in ap_process_request (r=0x81450bc) at http_request.c:1375
#10 0x80a34d2 in ap_process_http_connection (c=0x814315c) at
connection.c:251
#11 0x80a313f in ap_run_process_connection (c=0x814315c) at
connection.c:85
#12 0x80a33ed in ap_process_connection (c=0x814315c) at connection.c:223
#13 0x80944b1 in child_main (child_num_arg=0) at prefork.c:1048
#14 0x8094544 in make_child (s=0x81027d4, slot=0, now=977433739)
at prefork.c:1069
#15 0x8094694 in startup_children (number_to_start=5) at prefork.c:1143
#16 0x8094b82 in ap_mpm_run (_pconf=0x8101c3c, plog=0x8131dbc,
s=0x81027d4)
at prefork.c:1369
#17 0x809b20f in main (argc=1, argv=0xbffff7e4) at main.c:425
#18 0x400b4a2c in __libc_start_main (main=0x809ad20 <main>, argc=1,
ubp_av=0xbffff7e4, init=0x80592d8 <_init>, fini=0x80e024c <_fini>,
rtld_fini=0x4000d3c8 <_dl_fini>, stack_end=0xbffff7dc)
at ../sysdeps/generic/libc-start.c:111
and some possibly relevant debugging:
(gdb) up
#1 0x807f2cb in ap_http_filter (f=0x814333c, b=0x81457dc,
mode=AP_MODE_BLOCKING) at http_protocol.c:1008
1008 if ((rv = ap_bucket_read(e, &ignore, &len, mode)) !=
APR_SUCCESS) {
(gdb) print e
$1 = (ap_bucket *) 0x401b0c28
(gdb) print *e->type
$2 = {name = 0x81430ac "|0\024\b\n", num_func = 41,
destroy = 0x401b0c28 <main_arena+40>, read = 0x401b0c28
<main_arena+40>,
setaside = 0x80f3f8c <ap_heap_type>, split = 0, copy = 0x8175bc8}
Regards,
joe
Re: mod_dav unstable in 2.0
Posted by Joe Orton <jo...@light.plus.com>.
On Thu, Dec 21, 2000 at 02:36:31PM -0800, Ryan Bloom wrote:
>
> When did you update your 2.0 tree? There was a small bug fix in
> http_filter last night. I will try to debug this in a few minutes
> though.
My tree is current... I've got a much simpler test case which might be
the same problem, coming shortly.
joe
Re: mod_dav unstable in 2.0
Posted by rb...@covalent.net.
Well, I got mod_dav installed on my test machine, and configured, and then
I downloaded cadaver and compiled it. I then did the following:
./cadaver
open localhost:8080
cat .
ls
put /home/rbb/bio
quit
This all worked just fine, including the put. What platform are you
using? I am on a Linux box right now, but I am going to try it again on
FreeBSD soon-ish.
Ryan
On Thu, 21 Dec 2000, Joe Orton wrote:
> I'm getting lots of crashes with mod_dav in 2.0... I can reliably
> reproduce this by doing 'open www, cat ., ls' in cadaver, so the full
> stream of requests which go down the (single) connection are:
>
> OPTIONS /, PROPFIND /, GET /, PROPFIND /
>
> Here's the backtrace:
>
> #0 0x401b0c28 in main_arena () from /lib/libc.so.6
> #1 0x807f2cb in ap_http_filter (f=0x814333c, b=0x81457dc,
> mode=AP_MODE_BLOCKING) at http_protocol.c:1008
> #2 0x80a6102 in ap_get_brigade (next=0x814333c, bb=0x81457dc,
> mode=AP_MODE_BLOCKING) at util_filter.c:215
> #3 0x8082cc6 in ap_get_client_block (r=0x81450bc,
> buffer=0x8145eec "Thu, 21 Dec 2000 21:16:46 GMT", bufsiz=2048)
> at http_protocol.c:2857
> #4 0x80a4c33 in ap_xml_parse_input (r=0x81450bc, pdoc=0xbffff3bc)
> at util_xml.c:411
> #5 0x80629ef in dav_method_propfind (r=0x81450bc) at mod_dav.c:1547
> #6 0x8066bd6 in dav_handler (r=0x81450bc) at mod_dav.c:3866
> #7 0x80966f9 in ap_invoke_handler (r=0x81450bc) at config.c:364
> #8 0x80870a9 in process_request_internal (r=0x81450bc) at
> http_request.c:1348
> #9 0x8087181 in ap_process_request (r=0x81450bc) at http_request.c:1375
> #10 0x80a34d2 in ap_process_http_connection (c=0x814315c) at
> connection.c:251
> #11 0x80a313f in ap_run_process_connection (c=0x814315c) at
> connection.c:85
> #12 0x80a33ed in ap_process_connection (c=0x814315c) at connection.c:223
> #13 0x80944b1 in child_main (child_num_arg=0) at prefork.c:1048
> #14 0x8094544 in make_child (s=0x81027d4, slot=0, now=977433739)
> at prefork.c:1069
> #15 0x8094694 in startup_children (number_to_start=5) at prefork.c:1143
> #16 0x8094b82 in ap_mpm_run (_pconf=0x8101c3c, plog=0x8131dbc,
> s=0x81027d4)
> at prefork.c:1369
> #17 0x809b20f in main (argc=1, argv=0xbffff7e4) at main.c:425
> #18 0x400b4a2c in __libc_start_main (main=0x809ad20 <main>, argc=1,
> ubp_av=0xbffff7e4, init=0x80592d8 <_init>, fini=0x80e024c <_fini>,
> rtld_fini=0x4000d3c8 <_dl_fini>, stack_end=0xbffff7dc)
> at ../sysdeps/generic/libc-start.c:111
>
> and some possibly relevant debugging:
>
> (gdb) up
> #1 0x807f2cb in ap_http_filter (f=0x814333c, b=0x81457dc,
> mode=AP_MODE_BLOCKING) at http_protocol.c:1008
> 1008 if ((rv = ap_bucket_read(e, &ignore, &len, mode)) !=
> APR_SUCCESS) {
> (gdb) print e
> $1 = (ap_bucket *) 0x401b0c28
> (gdb) print *e->type
> $2 = {name = 0x81430ac "|0\024\b\n", num_func = 41,
> destroy = 0x401b0c28 <main_arena+40>, read = 0x401b0c28
> <main_arena+40>,
> setaside = 0x80f3f8c <ap_heap_type>, split = 0, copy = 0x8175bc8}
>
> Regards,
>
> joe
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: mod_dav unstable in 2.0
Posted by rb...@covalent.net.
When did you update your 2.0 tree? There was a small bug fix in
http_filter last night. I will try to debug this in a few minutes
though.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------