Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3F723195.8983E6E9@orcaware.com>
Date: Wed, 24 Sep 2003 17:06:45 -0700
From: Blair Zajac <blair@orcaware.com>
MIME-Version: 1.0
To: Stas Bekman <stas@stason.org>
CC: dev@apr.apache.org
Subject: Re: segfault in apr_atomic_cas
References: <3F721608.2030708@stason.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stas Bekman wrote:
> 
> When using apr built with --enable-pool-debug=all I get this segfault on the
> httpd server startup:
> 
> #0  0x4026cbe4 in apr_atomic_cas ()
>     from /home/stas/httpd/prefork/lib/libapr-0.so.0
> (gdb) where
> #0  0x4026cbe4 in apr_atomic_cas ()
>     from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #1  0x40268b2d in apr_thread_mutex_lock ()
>     from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #2  0x4026b77e in apr_pool_create_ex_debug ()
>     from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #3  0x40267685 in apr_initialize ()
>     from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #4  0x40267618 in apr_app_initialize ()
>     from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #5  0x080c6fb8 in main (argc=2, argv=0xbffff4e4) at main.c:426
> #6  0x40352c57 in __libc_start_main () from /lib/i686/libc.so.6
> 
> This happens because hash_mutex[] is not initialized when apr_pool_create is
> called.
> 
> The apr_atomic_init that initializes that variable is running too late:
> 
>      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;
>      }

Yes, I brought this up a month ago.

See the thread with the subject

"unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump"

Sander responded there, but there's been no work on it yet.

Best,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/