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 08:03:46 GMT


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?

Regards

RĂ¼diger


Mime
View raw message