log4cxx оставляя приложение в состоянии ожидания при выходе - PullRequest
Новая
       39

log4cxx оставляя приложение в состоянии ожидания при выходе

0 голосов
/ 30 сентября 2019

Я реализовал общую библиотеку libmy.so. В этой библиотеке я использовал log4cxx с asyncappender, используя DOMConfigurator :: configure (). Всякий раз, когда любое приложение, использующее мою общую библиотеку (libmy.so), пытается выйти, оно просто остается в состоянии ожидания. Я нашел несколько ссылок, но они не работают для меня.

Я отладил проблему с помощью GDB. Он показывает два потока log4cxx, все еще ожидающих блокировки.

Ниже приведены некоторые строки из дампа gdb в состоянии зависания: 

(gdb) bt
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f2317d0bb70 in pthread_cond_broadcast@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_broadcast.S:133
#2  0x00007f2319001b99 in apr_thread_cond_broadcast (cond=<optimized out>) at locks/unix/thread_cond.c:129
#3  0x00007f2318fe9048 in log4cxx::helpers::Condition::signalAll (this=<optimized out>) at condition.cpp:50
#4  0x00007f2318fe4fff in log4cxx::AsyncAppender::close (this=0xbbc0b0) at asyncappender.cpp:184
#5  0x00007f2318fe5446 in log4cxx::AsyncAppender::~AsyncAppender (this=this@entry=0xbbc0b0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at asyncappender.cpp:64
#6  0x00007f2318fe5869 in log4cxx::AsyncAppender::~AsyncAppender (this=0xbbc0b0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at asyncappender.cpp:66
#7  0x00007f2318fa1a44 in log4cxx::helpers::ObjectPtrT<log4cxx::Appender>::~ObjectPtrT (this=0xb99a40, __in_chrg=<optimized out>)
    at ../../../src/main/include/log4cxx/helpers/objectptr.h:100

(gdb) thread 2
[Switching to thread 2 (Thread 0x7f23152c4700 (LWP 20592))]
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135 in ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S
(gdb) bt
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f2317d09cfc in __pthread_mutex_cond_lock (mutex=0xbc41e8) at ../nptl/pthread_mutex_lock.c:115
#2  0x00007f2317d0b3f0 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:259
#3  0x00007f2319001abd in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68
#4  0x00007f2318fe9078 in log4cxx::helpers::Condition::await (this=this@entry=0xbbc0e0, mutex=...) at condition.cpp:64
#5  0x00007f2318fe5964 in log4cxx::AsyncAppender::dispatch (thread=thread@entry=0xbc6208, data=0xbbc0b0) at asyncappender.cpp:332
#6  0x00007f2318f98d8e in log4cxx::helpers::Thread::launcher (thread=0xbc6208, data=0xbc61f0) at threadcxx.cpp:100
#7  0x00007f2317d056ba in start_thread (arg=0x7f23152c4700) at pthread_create.c:333
#8  0x00007f2317a3b41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Я попытался очистить код с помощью __attribute__ ((destructor)). Поместитениже утверждения в деструкторе: 

log4cxx::LogManager::shutdown();
 log4cxx::LogManager::resetConfiguration();

Но это дает ошибку сегментации. Кажется, перед вызовом этих функций он уже вызвал ~ Logger (). Следовательно, я застрял либо в состоянии зависания, либо в результате сбоя. Я что-то пропустил?

...