httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Seg fault in mod_dav.
Date Thu, 11 Jan 2001 23:42:03 GMT

> > It is definately reproducable on my machine.  There are no other seg
> > faults on that machine.  The other seg faults are on  I'll
> > investigate this more.
> If you can get a backtrace, then I shouldn't have a problem figuring it out.

Sorry it took me so long to get this.

I am on FreeBSD 4.1-RELEASE, and I am using the prefork MPM.  I can
reproduce this problem VERY easily, and I can get you an account on this
machine Greg.  All I did was to start the server, and the I used cadaver
to connect to the server and I entered the command "rmcol manual".

Anyway, here's the stacktrace:

Program received signal SIGSEGV, Segmentation fault.
0x805e2f3 in dav_add_response (wres=0xbfbff64c, status=403, propstats=0x0)
    at mod_dav.c:1144
1144        resp = apr_pcalloc(ctx->w.pool, sizeof(*resp));
(gdb) where
#0  0x805e2f3 in dav_add_response (wres=0xbfbff64c, status=403,
    at mod_dav.c:1144
#1  0x805a852 in dav_fs_delete_walker (wres=0xbfbff64c, calltype=1)
    at repos.c:1245
#2  0x805abdf in dav_fs_walker (fsctx=0xbfbff648, depth=2147483646)
    at repos.c:1415
#3  0x805ac66 in dav_fs_walker (fsctx=0xbfbff648, depth=2147483647)
    at repos.c:1441
#4  0x805b0d8 in dav_fs_internal_walk (params=0xbfbff7c0,
    is_move=0, root_dst=0x0, response=0xbfbff7bc) at repos.c:1658
#5  0x805b10f in dav_fs_walk (params=0xbfbff7c0, depth=2147483647,
    response=0xbfbff7bc) at repos.c:1667
#6  0x805a8b2 in dav_fs_remove_resource (resource=0x8143eac,
    response=0xbfbff810) at repos.c:1274
#7  0x805e48b in dav_method_delete (r=0x814203c) at mod_dav.c:1234
#8  0x8061892 in dav_handler (r=0x814203c) at mod_dav.c:3858
#9  0x808247c in ap_invoke_handler (r=0x814203c) at config.c:364
#10 0x8074778 in process_request_internal (r=0x814203c) at
#11 0x807481b in ap_process_request (r=0x814203c) at http_request.c:1375
#12 0x808b04f in ap_process_http_connection (c=0x813f0ec) at
#13 0x808adec in ap_run_process_connection (c=0x813f0ec) at
#14 0x808af74 in ap_process_connection (c=0x813f0ec) at connection.c:221
#15 0x8080bf0 in child_main (child_num_arg=0) at prefork.c:1048
---Type <return> to continue, or q <return> to quit---
#16 0x8080c80 in make_child (s=0x80dbba4, slot=0, now=979265431)
    at prefork.c:1069
#17 0x8080d8f in startup_children (number_to_start=5) at prefork.c:1143
#18 0x8081115 in ap_mpm_run (_pconf=0x80db00c, plog=0x812300c,
    at prefork.c:1369
#19 0x8085a0e in main (argc=1, argv=0xbfbffb3c) at main.c:427
#20 0x80589a5 in _start ()

And some other potentially useful information:

(gdb) l
1139    {
1140        dav_walker_ctx *ctx = wres->walk_ctx;
1141        dav_response *resp;
1143        /* just drop some data into an dav_response */
1144        resp = apr_pcalloc(ctx->w.pool, sizeof(*resp));
1145        resp->href = apr_pstrdup(ctx->w.pool, wres->resource->uri);
1146        resp->status = status;
1147        if (propstats) {
1148            resp->propresult = *propstats;
(gdb) p ctx
$1 = (dav_walker_ctx *) 0x0
(gdb) p *wres
$2 = {walk_ctx = 0x0, resource = 0xbfbff658, response = 0x0}

If you need anything Greg, just let me know.  If you want to give me a
pointer or two so that I look in the right place, I can do that too.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message