subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lieven Govaerts <...@apache.org>
Subject Segfault in mod_dav_svn with repositories on /
Date Fri, 10 Jan 2014 10:53:20 GMT
Hi,


a customer is seeing reproducible httpd child process segfaults when
using Subversion.

Setup:
- Subversion 1.8.1 - WANDisco package subversion-1.8.1-1.x86_64.rpm
- Apache 2.2.15 - RedHat package httpd-2.2.15-26.el6.x86_64
- OS: Red Hat Enterprise Linux Server release 6.4
- Client: svn, version 1.7.9-SlikSvn-1.7.9-WIN32 (SlikSvn/1.7.9) WIN32

Apache is configured to use the prefork module. For Subversion we use
mod_dav_svn, but not mod_authz_svn.

We have a few svn repositories, all located on the root of the server.
Relevant extra of httpd config:
<Location />
 DAV svn
 SVNParentPath /data/scm/repositories/
 SVNListParentPath on
 SVNPathAuthz off
 ...
</Location>

A correct url in our setup is https://scm/repo.

Issue:
With this configuration, we can get httpd child processes to crash
systematically by connecting to the root of the server:
$ svn ls https://scm/
..
svn: E175002: Unable to connect to a repository at URL 'https://scm'
svn: E175002: OPTIONS of 'https://scm': Could not read status line:
Secure connection truncated (https://scm)

In the httpd access logs we see:
10.50.148.71 - - [20/Dec/2013:15:10:54 +0100] "OPTIONS / HTTP/1.1" 401 472

And in error.log (after activating core dump generation and
installation of debuginfo rpm's):
[Fri Dec 20 15:10:58 2013] [notice] child pid 18905 exit signal
Segmentation fault (11), possible coredump in /data/httpd/coredumps/

Core dump stacktrace:
$ gdb /usr/sbin/httpd core.17002
Program terminated with signal 11, Segmentation fault.
#0  dav_svn__build_uri (repos=<value optimized out>,
what=DAV_SVN__BUILD_URI_PUBLIC, revision=-1,
    path=<value optimized out>, add_href=0, pool=0x7f8ca55ba368) at
subversion/mod_dav_svn/util.c:249
249       if (root_path[1] == '\0')
(gdb) bt
#0  dav_svn__build_uri (repos=<value optimized out>,
what=DAV_SVN__BUILD_URI_PUBLIC, revision=-1,
    path=<value optimized out>, add_href=0, pool=0x7f8ca55ba368) at
subversion/mod_dav_svn/util.c:249
#1  0x00007f8c9794aed4 in get_option (resource=0x7f8ca55d2948,
elem=0x7f8ca55d2d30, option=0x7ffffcd83820)
    at subversion/mod_dav_svn/version.c:180
#2  0x00007f8c9c19539a in dav_method_options (r=<value optimized out>)
    at /usr/src/debug/httpd-2.2.15/modules/dav/main/mod_dav.c:1840
#3  0x00007f8c9c195fe8 in dav_handler (r=0x7f8ca55ba3e8)
    at /usr/src/debug/httpd-2.2.15/modules/dav/main/mod_dav.c:4650
#4  0x00007f8ca3630bb0 in ap_run_handler (r=0x7f8ca55ba3e8) at
/usr/src/debug/httpd-2.2.15/server/config.c:158
#5  0x00007f8ca363446e in ap_invoke_handler (r=0x7f8ca55ba3e8) at
/usr/src/debug/httpd-2.2.15/server/config.c:376
#6  0x00007f8ca363fb30 in ap_process_request (r=0x7f8ca55ba3e8)
    at /usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
#7  0x00007f8ca363c9a8 in ap_process_http_connection (c=0x7f8ca548d7b8)
    at /usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
#8  0x00007f8ca36386b8 in ap_run_process_connection (c=0x7f8ca548d7b8)
    at /usr/src/debug/httpd-2.2.15/server/connection.c:43
#9  0x00007f8ca3644977 in child_main (child_num_arg=<value optimized out>)
    at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:667
#10 0x00007f8ca3644c8a in make_child (s=0x7f8ca5301860, slot=12)
    at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:763
#11 0x00007f8ca364590c in perform_idle_server_maintenance
(_pconf=<value optimized out>,
    plog=<value optimized out>, s=<value optimized out>)
    at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:898
#12 ap_mpm_run (_pconf=<value optimized out>, plog=<value optimized
out>, s=<value optimized out>)
    at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:1102
#13 0x00007f8ca361c900 in main (argc=3, argv=0x7ffffcd83e68) at
/usr/src/debug/httpd-2.2.15/server/main.c:760


Looking at the code at the crash location, this looks like a simple
case of an incorrect assumption:

246:  /* The first character of root_path is guaranteed to be "/".  If
247:     there's no component beyond that, then just use "", so that
248:     appending another "/" later does not result in "//". */
249:  if (root_path[1] == '\0')
250:    root_path = "";

I'm wondering if this simple change will solve the issue (can't test
it here/now):

249:  if (root_path[0] == '\0' || root_path[1] == '\0')
250:    root_path = "";

Lieven

Mime
View raw message