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?
Thanks and regards,
Rainer
