apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump
Date Fri, 22 Aug 2003 04:13:49 GMT
> From: Blair Zajac [mailto:blair@orcaware.com]
> Sent: Thursday, August 21, 2003 11:49 PM

Hi Blair!

> I tracked my core dump down to the following combination.
> Using apr CVS HEAD with --enable-pool-debug=yes and with thread_mutex
> 1.19 or greater causes the coredumps in apr/test/testall I reported in
> my messages with the subject "testall core dump with apr HEAD".  Backing
> thread_mutex.c down to 1.18 has no problems with -enable-pool-debug=yes.

The introduction of atomics in the thread_mutex code.  Let's see...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1074592640 (LWP 16810)]
0x4003356e in apr_atomic_cas (mem=0x80c10b8, with=0, cmp=0) at apr_atomic.c:166
166         apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];
(gdb) bt
#0  0x4003356e in apr_atomic_cas (mem=0x80c10b8, with=0, cmp=0)
    at apr_atomic.c:166
#1  0x40019944 in _r_debug ()
   from /export/home1/blair/Code/Apache/2.0/h/srclib/apr/.libs/libapr-0.so.0
#2  0x4002fe0a in apr_thread_mutex_lock (mutex=0x0) at thread_mutex.c:129
#3  0x4003219a in apr_pool_create_ex_debug (newpool=0xbfffed40,
    parent=0x80c1048, abort_fn=0, allocator=0x0,
    file_line=0x40035a83 "start.c:96") at apr_pools.c:1540
#4  0x4002e512 in apr_initialize () at start.c:96

Right.  The core dump happens when apr_atomic_init() hasn't been called yet.

>From apr_initialize()  [misc/unix/start.c]
    if ((status = apr_pool_initialize()) != APR_SUCCESS)
        return status;

    if (apr_pool_create(&pool, NULL) != APR_SUCCESS) {
        return APR_ENOPOOL;

    apr_pool_tag(pool, "apr_initialize");

    if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
        return status;

Since pools depend on apr_thread_mutex-es, the atomics change might
have introduced a circular dependency.  And we're getting bit by
it in the debug code.  Stepping through the code will positively
point out where the thread mutexes are first used before
apr_atomic_init() is called.  If you get around to that before I do
please post ;) :).
> I'm on RedHat 9 and I've used the RedHat gcc 3.2.2 and my own gcc 3.3.1
> and they both have the same behavior.
> I haven't received any response to my previous messages, so I'd
> appreciate some advice in getting a response from the APR developers.
> It seems that other messages from APR newbies that ask questions
> implying that they did no homework on reading APR documentation
> gets more of a response then somebody who's got a decent amount of
> feedback to a core dump from an APR supplied program, which isn't
> obviously then operator error.  So the question is, what's missing
> in my reports to get a response.

Nothing.  Sorry for the late reply.
> I do like to contribute, so anything to make this easier for me
> would be appreciated.
> I'm hoping I've narrowed this problem down to a small enough
> changeset where somebody that's familar with the locking code
> can make quick progress on this bug.
> BTW, I'm using --enable-pool-debug=yes with APR as part of
> Subversion.


View raw message