More details. YAY
First, a stack trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 18642)]
0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762
1762if ((err = (*vsn_hooks-get_option)(resource, elem,
body))
(gdb) where
#0 0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762
#1 0x403d3424 in dav_handler (r=0x8123470) at mod_dav.c:4507
#2 0x08064db8 in ap_run_handler (r=0x8123470) at config.c:194
#3 0x0806533d in ap_invoke_handler (r=0x8123470) at config.c:401
#4 0x080624c6 in ap_process_request (r=0x8123470) at http_request.c:288
#5 0x0805e28b in ap_process_http_connection (c=0x811d528) at
http_core.c:293
#6 0x0806d138 in ap_run_process_connection (c=0x811d528) at
connection.c:85
#7 0x0806d3e3 in ap_process_connection (c=0x811d528, csd=0x811d458)
at connection.c:207
#8 0x08063a4a in child_main (child_num_arg=0) at prefork.c:696
#9 0x08063b08 in make_child (s=0x80996f0, slot=0) at prefork.c:736
#10 0x08063bfe in startup_children (number_to_start=5) at prefork.c:808
#11 0x08063f0c in ap_mpm_run (_pconf=0x8097950, plog=0x80c19f8,
s=0x80996f0)
at prefork.c:1024
#12 0x0806958c in main (argc=4, argv=0xbba4) at main.c:643
#13 0x402943c1 in __libc_start_main () from /lib/libc.so.6
Next, the value of vsn_hooks:
gdb) p vsn_hooks
$1 = (dav_hooks_vsn *) 0x0
Finally, the config and the problem:
Location /svn/repos
Dav svn
SVNPath /svn
# snipped for brevity, not the cuase
/Location
The problem is that I was requesting:
svn import http://www.rkbloom.net/svn mumble
Notice that the config is /svn/repos, but the command is /svn. There is
no /svn, so I should have gotten a 404 back.
Ryan
On Wed, 18 Sep 2002, Greg Stein wrote:
On Wed, Sep 18, 2002 at 06:49:48PM -0400, [EMAIL PROTECTED] wrote:
I don't know if this is in .41 because I haven't had time to test it
yet. But, HEAD of mod_dav has an annoying seg fault. Basically, if you
send an OPTIONS request for a location that isn't configured for DAV, the
module seg faults. I have traced it far enough to know where it is
happening, but the fix shouldn't require that information.
Basically, the mod_dav handler should be ensuring that Dav has been given
a provider for the current location before it tries to handle the request.
If this bug exists in 2.0.41, then -1 for GA. I will try to test .41
later tonight, and to create a patch at the same time.
I'm not seeing that problem:
[gstein@roshi test]$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
OPTIONS /icons/ HTTP/1.0
host: roshi.collab.net
HTTP/1.1 200 OK
Date: Wed, 18 Sep 2002 23:26:28 GMT
Server: Apache/2.0.41 (Unix) DAV/2
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Connection: close
Content-Type: httpd/unix-directory
Connection closed by foreign host.
[gstein@roshi test]$
(I'm not sure that the above code is exactly 2.0.41, but something close)
I'm updating to HEAD to check this out some more. Can you provide a
backtrace for what you're seeing?
Cheers,
-g
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
