apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <bl...@orcaware.com>
Subject Re: segfault in apr_atomic_cas
Date Thu, 25 Sep 2003 00:06:45 GMT
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/

Mime
View raw message