subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bailey, Aaron" <Aaron.Bai...@ga.com>
Subject Bug Report Againgst Subversion 1.9.3 libsvn_subr
Date Fri, 08 Jul 2016 18:45:11 GMT
To Whom It May Concern,

This email is in regards to a potential software bug I've encountered in Subversion 1.9.3.
I wasn't really able to find anything on the existing issue tracker, however that may be due
to my inability to get any useful information out of it. As directed on the issues page I'm
first emailing this list about the potential bug.


Summary:
I'm attempting to upgrade a Subversion server to 1.9.3. My distro doesn't provide a package
for newer versions of Subversion. So I've built my own package and after building the mod_dav_svn
package I've been encountering some issues. Specifically, when Apache, in this case 2.2.15,
runs it gets a segmentation fault when loading the dav_svn_module (mod_dav_svn.so). I've been
looking at the stack trace I get from the core file and it appears to be an issue with how
libsvn_subr is attempting to use the apr_pools.c module. I believe this is a bug and not an
issue with my build. I will present the information I've found below, please be patient as
I'm unable to copy &paste.


Details:
Software Versions:
SUBVERSION  1.9.3
APR                    1.5.2
APR-UTIL         1.5.4
SCONS              2.5.0
SERF                  1.3.8

Stack Trace:
#0  in apr_pool_create_ex
---------------------------------APR libs from here down the stack
#1  in svn_pool_create_ex
#2  in atomic_init_func
#3  in svn_atomic__init_once
#4  in svn_dso_initialize2
#5  in init_dso
---------------------------------SUBVERSION libs from here down the stack
#6  in ap_run_pre_config
#7  in main

Analysis:
The segmentation fault occurs in the code segment below from the module memory/unix/apr_pools.c:
"""
if (allocator == NULL)
    allocator = parent->allocator; // <-- This line segfaults
"""

Near the above code block provided above there is a comment about how the parent object will
always be non-NULL except the first time. During the first pool create call it is supposed
to be guaranteed that
the allocator object is not NULL. Since the parent object was NULL as this is the first call
to pool create
it is set to global_pool. However, global_pool is NULL and the passed in allocator is NULL.
This appears to disagree with the apr_pool_create_ex functions API as specified in the code
and comments.

This seemingly invalid call to the apr_pool_create_ex function stems from the atomic_init_func
function in the module
libsvn_subr/dso.c which makes a call to the pre-processor macro svn_pool_create with a single
argument of NULL.
As best I can tell this macro is defined in the module include/svn_pools.h. It is defined
as
"""
/** Create a pool as a subpool of @a parent_pool */
#define svn_pool_create(parent_pool) svn_pool_create_ex(parent_pool, NULL)
"""
Since this is the first call to the apr_pool_create_ex function it would appear to be valid
to have a NULL parent_pool, but invalid
to then additionally have a NULL allocator.

Thanks,

Aaron


Mime
View raw message