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 <[EMAIL PROTECTED]>
Plots of your system's performance - http://www.orcaware.com/orca/
