apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: crash during httpd cleanup when using APR debug library (APR_POOL_DEBUG)
Date Wed, 17 Jul 2019 10:09:41 GMT


On 07/17/2019 11:43 AM, Rainer Jung wrote:
> Am 17.07.2019 um 10:03 schrieb Ruediger Pluem:
>>
>>
>> On 07/16/2019 11:28 PM, Rainer Jung wrote:
>>> cross-posted to APR+HTTPD
>>>
>>> Crahs happens in #2  0x00007faf4c154945 in raise () from /lib64/libc.so.6
>>> #3  0x00007faf4c155f21 in abort () from /lib64/libc.so.6
>>> #4  0x00007faf4c14d810 in __assert_fail () from /lib64/libc.so.6
>>> #5  0x00007faf4c694219 in __pthread_tpp_change_priority () from /lib64/libpthread.so.0
>>> #6  0x00007faf4c68cd76 in __pthread_mutex_lock_full () from /lib64/libpthread.so.0
>>> #7  0x00007faf4cd07c29 in apr_thread_mutex_lock (mutex=0x2261fe0) at locks/unix/thread_mutex.c:108
>>> #8  0x00007faf4cd08603 in apr_pool_walk_tree (pool=0x225a710, fn=0x7faf4cd07fc0
<pool_num_bytes>, data=0x7faf45777c90)
>>> at memory/unix/apr_pools.c:1515
>>> #9  0x00007faf4cd08630 in apr_pool_walk_tree (pool=0x6a3ce0, fn=0x7faf4cd07fc0
<pool_num_bytes>, data=0x7faf45777c90) at
>>> memory/unix/apr_pools.c:1521
>>> #10 0x00007faf4cd08630 in apr_pool_walk_tree (pool=0x6a3770, fn=0x7faf4cd07fc0
<pool_num_bytes>, data=0x7faf45777c90) at
>>> memory/unix/apr_pools.c:1521
>>> #11 0x00007faf4cd08630 in apr_pool_walk_tree (pool=0x6a3110, fn=0x7faf4cd07fc0
<pool_num_bytes>, data=0x7faf45777c90) at
>>> memory/unix/apr_pools.c:1521
>>> #12 0x00007faf4cd086df in apr_pool_num_bytes (pool=0x6d81, recurse=<value
optimized out>) at
>>> memory/unix/apr_pools.c:2304
>>> #13 0x00007faf4cd0898f in apr_pool_log_event (pool=0x225a710, event=0x7faf4cd16e74
"PCALLOC", file_line=0x7faf4cd16d78
>>> "locks/unix/thread_mutex.c:50", deref=-1)
>>>      at memory/unix/apr_pools.c:1543
>>> #14 0x00007faf4cd098b8 in apr_pcalloc_debug (pool=0x225a710, size=64, file_line=0x7faf4cd16d78
>>> "locks/unix/thread_mutex.c:50") at memory/unix/apr_pools.c:1814
>>> #15 0x00007faf4cd07ce5 in apr_thread_mutex_create (mutex=0x225a798, flags=1,
pool=0x225a710) at
>>> locks/unix/thread_mutex.c:50
>>> #16 0x00007faf4cd0a164 in apr_pool_clear_debug (pool=0x225a710, file_line=0x488f09
"mpm_fdqueue.c:236") at
>>> memory/unix/apr_pools.c:1911
>>> #17 0x000000000046c455 in ap_queue_info_push_pool (queue_info=0x22648b0, pool_to_recycle=0x225a710)
at mpm_fdqueue.c:236
>>> #18 0x00007faf4bf18821 in process_lingering_close (cs=0x78d670) at event.c:1457
>>> #19 0x00007faf4bf196a8 in worker_thread (thd=0x6cae80, dummy=<value optimized
out>) at event.c:2083
>>> #20 0x00007faf4c68b5f0 in start_thread () from /lib64/libpthread.so.0
>>> #21 0x00007faf4c1f684d in clone () from /lib64/libc.so.6
>>>
>>> So it seems a mutex gets created, which allocates memory, which in turn triggers
debug logging, which walks pools and
>>> finally tries to lock the not yet initialized lock.
>>>
>>> Anyone aware of that? Any ideas how to fix?
>>
>> This is strange. Before apr_thread_mutex_create is called by apr_pool_clear_debug
pool->mutex is set to NULL. So IMHO in
>> frame #7 mutex should be NULL.
>> Which version of APR are you using?
> 
> 1.7 with a few debug patches, that should really not make a difference here (but might
offset line numbers a bit).
> 1.7.0, 1.7.x, 1.6.5 and 1.6.x do not differ in apr_pools.c.

I was looking at apr trunk. Maybe r1481186 fixes your issue.

Regards

RĂ¼diger


Mime
View raw message