Blair Zajac wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
|