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
