You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rob Kooper <ko...@ncsa.illinois.edu> on 2010/11/04 03:54:57 UTC
apache coredump in mod_dav_svn
I'm getting a core dump in mod_dav_svn, here is the backtrace:
(gdb) bt full
#0 0x00007f6a31d5a9c3 in svn_stringbuf_dup () from /usr/lib/libsvn_subr-1.so.1
No symbol table info available.
#1 0x00007f6a325c7284 in ?? () from /usr/lib/apache2/modules/mod_dav_svn.so
No symbol table info available.
#2 0x00007f6a327e11de in ?? () from /usr/lib/apache2/modules/mod_dav.so
No symbol table info available.
#3 0x00007f6a327e2578 in ?? () from /usr/lib/apache2/modules/mod_dav.so
No symbol table info available.
#4 0x00007f6a35516380 in ap_run_handler (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/server/config.c:159
n = 3
rv = 963463992
#5 0x00007f6a35519ce8 in ap_invoke_handler (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x0
result = 0
old_handler = 0x7f6a327e8168 "dav-handler"
ignore = <value optimized out>
#6 0x00007f6a355275e8 in ap_process_request (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/modules/http/http_request.c:282
access_status = 963463992
#7 0x00007f6a35524498 in ap_process_http_connection (c=0x7f6a386592f0) at /build/buildd/apache2-2.2.14/modules/http/http_core.c:190
r = 0x7f6a396d4bb8
csd = 0x0
#8 0x00007f6a3551df38 in ap_run_process_connection (c=0x7f6a386592f0) at /build/buildd/apache2-2.2.14/server/connection.c:43
n = 2
rv = 963463992
#9 0x00007f6a3552ce82 in process_socket (thd=<value optimized out>, dummy=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/worker/worker.c:544
current_conn = <value optimized out>
conn_id = <value optimized out>
csd = 23
sbh = 0x7f6a386592e8
#10 worker_thread (thd=<value optimized out>, dummy=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/worker/worker.c:894
process_slot = 0
thread_slot = 16
csd = 0x7f6a386590d8
bucket_alloc = <value optimized out>
last_ptrans = <value optimized out>
ptrans = 0x7f6a38659048
rv = <value optimized out>
is_idle = <value optimized out>
#11 0x00007f6a34c532ff in ?? () from /usr/lib/libapr-1.so.0
No symbol table info available.
#12 0x00007f6a34a139ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#13 0x00007f6a3477070d in clone () from /lib/libc.so.6
No symbol table info available.
#14 0x0000000000000000 in ?? ()
No symbol table info available.
This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen:
curl --request PROPFIND --header "Depth: 1" https://host/svn/
The section from apache.conf is:
<Location /svn>
# Uncomment this to enable the repository
DAV svn
# Set this to the path to your repository
SVNParentPath /home/svn
SVNListParentPath on
</Location>
Is this a known issue or do I have something wrong.
Rob
--
Rob Kooper
1205 W. Clark St, MC-257
Urbana, IL 61801
217-333-3593
kooper@ncsa.illinois.edu
mod_dav_svn segfaults upon PROPFIND to the SVNParentPath location
(was: Re: apache coredump in mod_dav_svn)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Moving to dev@. (Please drop users@ from follow-ups.)
Summary: segfault in mod_dav_svn with PROPFIND at the SVNParentPath
location, reproducable with trunk.
Daniel Shahaf wrote on Fri, Nov 05, 2010 at 14:03:26 +0200:
> Rob Kooper wrote on Wed, Nov 03, 2010 at 22:54:57 -0500:
> > I'm getting a core dump in mod_dav_svn, here is the backtrace:
> >
> ...
> >
> > This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen:
> >
> > curl --request PROPFIND --header "Depth: 1" https://host/svn/
> >
> > The section from apache.conf is:
> >
> > <Location /svn>
> > # Uncomment this to enable the repository
> > DAV svn
> >
> > # Set this to the path to your repository
> > SVNParentPath /home/svn
> > SVNListParentPath on
> > </Location>
> >
> > Is this a known issue or do I have something wrong.
>
> Thanks for the report. I can reproduce it with current trunk:
>
> (gdb) bt
> #0 0xb749d640 in svn_stringbuf_dup (original_string=0x0, pool=0x8402518)
> at subversion/libsvn_subr/svn_string.c:509
> #1 0xb751556e in walk (params=0xbfce3780, depth=1, response=0xbfce37d0)
> at subversion/mod_dav_svn/repos.c:4139
> #2 0x0809f94f in dav_method_propfind (r=0x8402558) at mod_dav.c:2064
> #3 0x080a362c in dav_handler (r=0x8402558) at mod_dav.c:4649
> #4 0x0807d9f9 in ap_run_handler (r=0x8402558) at config.c:158
> #5 0x08080d7e in ap_invoke_handler (r=0x8402558) at config.c:376
> #6 0x080988d6 in ap_process_request (r=0x8402558) at http_request.c:282
> #7 0x08095858 in ap_process_http_connection (c=0x83fe6e0) at http_core.c:190
> #8 0x08084eb9 in ap_run_process_connection (c=0x83fe6e0) at connection.c:43
> #9 0x080beb5d in child_main (child_num_arg=<value optimized out>) at prefork.c:662
> #10 0x080bee27 in make_child (s=0x834f098, slot=0) at prefork.c:707
> #11 0x080bf532 in ap_mpm_run (_pconf=0x834a0a8, plog=0x838e1b8, s=0x834f098) at prefork.c:983
> #12 0x0806a490 in main (argc=Cannot access memory at address 0x0) at main.c:739
>
mod_dav_svn segfaults upon PROPFIND to the SVNParentPath location
(was: Re: apache coredump in mod_dav_svn)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Moving to dev@. (Please drop users@ from follow-ups.)
Summary: segfault in mod_dav_svn with PROPFIND at the SVNParentPath
location, reproducable with trunk.
Daniel Shahaf wrote on Fri, Nov 05, 2010 at 14:03:26 +0200:
> Rob Kooper wrote on Wed, Nov 03, 2010 at 22:54:57 -0500:
> > I'm getting a core dump in mod_dav_svn, here is the backtrace:
> >
> ...
> >
> > This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen:
> >
> > curl --request PROPFIND --header "Depth: 1" https://host/svn/
> >
> > The section from apache.conf is:
> >
> > <Location /svn>
> > # Uncomment this to enable the repository
> > DAV svn
> >
> > # Set this to the path to your repository
> > SVNParentPath /home/svn
> > SVNListParentPath on
> > </Location>
> >
> > Is this a known issue or do I have something wrong.
>
> Thanks for the report. I can reproduce it with current trunk:
>
> (gdb) bt
> #0 0xb749d640 in svn_stringbuf_dup (original_string=0x0, pool=0x8402518)
> at subversion/libsvn_subr/svn_string.c:509
> #1 0xb751556e in walk (params=0xbfce3780, depth=1, response=0xbfce37d0)
> at subversion/mod_dav_svn/repos.c:4139
> #2 0x0809f94f in dav_method_propfind (r=0x8402558) at mod_dav.c:2064
> #3 0x080a362c in dav_handler (r=0x8402558) at mod_dav.c:4649
> #4 0x0807d9f9 in ap_run_handler (r=0x8402558) at config.c:158
> #5 0x08080d7e in ap_invoke_handler (r=0x8402558) at config.c:376
> #6 0x080988d6 in ap_process_request (r=0x8402558) at http_request.c:282
> #7 0x08095858 in ap_process_http_connection (c=0x83fe6e0) at http_core.c:190
> #8 0x08084eb9 in ap_run_process_connection (c=0x83fe6e0) at connection.c:43
> #9 0x080beb5d in child_main (child_num_arg=<value optimized out>) at prefork.c:662
> #10 0x080bee27 in make_child (s=0x834f098, slot=0) at prefork.c:707
> #11 0x080bf532 in ap_mpm_run (_pconf=0x834a0a8, plog=0x838e1b8, s=0x834f098) at prefork.c:983
> #12 0x0806a490 in main (argc=Cannot access memory at address 0x0) at main.c:739
>
Re: apache coredump in mod_dav_svn
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Rob Kooper wrote on Wed, Nov 03, 2010 at 22:54:57 -0500:
> I'm getting a core dump in mod_dav_svn, here is the backtrace:
>
...
>
> This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen:
>
> curl --request PROPFIND --header "Depth: 1" https://host/svn/
>
> The section from apache.conf is:
>
> <Location /svn>
> # Uncomment this to enable the repository
> DAV svn
>
> # Set this to the path to your repository
> SVNParentPath /home/svn
> SVNListParentPath on
> </Location>
>
> Is this a known issue or do I have something wrong.
Thanks for the report. I can reproduce it with current trunk:
(gdb) bt
#0 0xb749d640 in svn_stringbuf_dup (original_string=0x0, pool=0x8402518)
at subversion/libsvn_subr/svn_string.c:509
#1 0xb751556e in walk (params=0xbfce3780, depth=1, response=0xbfce37d0)
at subversion/mod_dav_svn/repos.c:4139
#2 0x0809f94f in dav_method_propfind (r=0x8402558) at mod_dav.c:2064
#3 0x080a362c in dav_handler (r=0x8402558) at mod_dav.c:4649
#4 0x0807d9f9 in ap_run_handler (r=0x8402558) at config.c:158
#5 0x08080d7e in ap_invoke_handler (r=0x8402558) at config.c:376
#6 0x080988d6 in ap_process_request (r=0x8402558) at http_request.c:282
#7 0x08095858 in ap_process_http_connection (c=0x83fe6e0) at http_core.c:190
#8 0x08084eb9 in ap_run_process_connection (c=0x83fe6e0) at connection.c:43
#9 0x080beb5d in child_main (child_num_arg=<value optimized out>) at prefork.c:662
#10 0x080bee27 in make_child (s=0x834f098, slot=0) at prefork.c:707
#11 0x080bf532 in ap_mpm_run (_pconf=0x834a0a8, plog=0x838e1b8, s=0x834f098) at prefork.c:983
#12 0x0806a490 in main (argc=Cannot access memory at address 0x0) at main.c:739
Re: apache coredump in mod_dav_svn
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
Perhaps you could also supply what your OS, Apache version, and
Subversion version are? Are you up to Subversion 1.6.13, and did you
build it yourself or are you using your particular OS's packaged
version?
On Wed, Nov 3, 2010 at 11:54 PM, Rob Kooper <ko...@ncsa.illinois.edu> wrote:
> I'm getting a core dump in mod_dav_svn, here is the backtrace:
>
> (gdb) bt full
> #0 0x00007f6a31d5a9c3 in svn_stringbuf_dup () from /usr/lib/libsvn_subr-1.so.1
> No symbol table info available.
> #1 0x00007f6a325c7284 in ?? () from /usr/lib/apache2/modules/mod_dav_svn.so
> No symbol table info available.
> #2 0x00007f6a327e11de in ?? () from /usr/lib/apache2/modules/mod_dav.so
> No symbol table info available.
> #3 0x00007f6a327e2578 in ?? () from /usr/lib/apache2/modules/mod_dav.so
> No symbol table info available.
> #4 0x00007f6a35516380 in ap_run_handler (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/server/config.c:159
> n = 3
> rv = 963463992
> #5 0x00007f6a35519ce8 in ap_invoke_handler (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/server/config.c:373
> handler = 0x0
> result = 0
> old_handler = 0x7f6a327e8168 "dav-handler"
> ignore = <value optimized out>
> #6 0x00007f6a355275e8 in ap_process_request (r=0x7f6a396d4bb8) at /build/buildd/apache2-2.2.14/modules/http/http_request.c:282
> access_status = 963463992
> #7 0x00007f6a35524498 in ap_process_http_connection (c=0x7f6a386592f0) at /build/buildd/apache2-2.2.14/modules/http/http_core.c:190
> r = 0x7f6a396d4bb8
> csd = 0x0
> #8 0x00007f6a3551df38 in ap_run_process_connection (c=0x7f6a386592f0) at /build/buildd/apache2-2.2.14/server/connection.c:43
> n = 2
> rv = 963463992
> #9 0x00007f6a3552ce82 in process_socket (thd=<value optimized out>, dummy=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/worker/worker.c:544
> current_conn = <value optimized out>
> conn_id = <value optimized out>
> csd = 23
> sbh = 0x7f6a386592e8
> #10 worker_thread (thd=<value optimized out>, dummy=<value optimized out>) at /build/buildd/apache2-2.2.14/server/mpm/worker/worker.c:894
> process_slot = 0
> thread_slot = 16
> csd = 0x7f6a386590d8
> bucket_alloc = <value optimized out>
> last_ptrans = <value optimized out>
> ptrans = 0x7f6a38659048
> rv = <value optimized out>
> is_idle = <value optimized out>
> #11 0x00007f6a34c532ff in ?? () from /usr/lib/libapr-1.so.0
> No symbol table info available.
> #12 0x00007f6a34a139ca in start_thread () from /lib/libpthread.so.0
> No symbol table info available.
> #13 0x00007f6a3477070d in clone () from /lib/libc.so.6
> No symbol table info available.
> #14 0x0000000000000000 in ?? ()
> No symbol table info available.
>
> This seems to happen when a propfind is performed on the parentpath of my repository. Running the following curl makes the coredump happen:
>
> curl --request PROPFIND --header "Depth: 1" https://host/svn/
>
> The section from apache.conf is:
>
> <Location /svn>
> # Uncomment this to enable the repository
> DAV svn
>
> # Set this to the path to your repository
> SVNParentPath /home/svn
> SVNListParentPath on
> </Location>
>
> Is this a known issue or do I have something wrong.
>
> Rob
> --
> Rob Kooper
> 1205 W. Clark St, MC-257
> Urbana, IL 61801
> 217-333-3593
> kooper@ncsa.illinois.edu
>
>
>
>