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.
I hoped that I'll never need to do that, so I was ignoring any threads on that subject. Now we have several problems with pools that I need to debug before I can report them.
I have a dirty workaround, setting global_pool->mutex to NULL, at least I can do some debugging.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
