I don't see args in your backtrace, perhaps rebuild apr + your app with -g, or if it is a system package, install corresponding debuginfo for apr? On Oct 3, 2015 10:48, "Loïc BLOT" <loic.b...@unix-experience.fr> wrote:
> Hello dev@apr.apache.org > Thanks for your library, it's very useful. > > I experienced a behaviour i am unable to solve. I implemented libapr in > a C++ program to make our program more portable on C++ & threads. > > My apr_thread_mutex_t* is declared in a single class which permit to > call lock and unlock. I also have a RAII class. > The APRMutex class use pool to create the mutex in the constructor and > call apr_thread_mutex_destroy > > You'll find APRMutex class sample here: http://pastie.org/10458413 and > RAII class here: http://pastie.org/10458414 > > The behaviour i experienced is simple. Sometimes, when an object > destructor is called and object has a APRMutex member, the program > freeze and the destructor calling thread and this thread uses 100% CPU > and is stucked. > > Here you will see a gdb live trace: > > (gdb) info threads > 6 Thread 804406c00 (LWP 100534/ConnectionReceive) 0x0000000802f1deea > in _select () from /lib/libc.so.7 > 5 Thread 804410800 (LWP 100911/ServerThread) 0x0000000800ff755c in > apr_pool_cleanup_run () from /usr/local/lib/libapr-1.so.0 > > (gdb) thread 5 > [Switching to thread 5 (Thread 804410800 (LWP > 100911/ServerThread))]#0 0x0000000800ff755c in apr_pool_cleanup_run () > from /usr/local/lib/libapr-1.so.0 > (gdb) bt > #0 0x0000000800ff755c in apr_pool_cleanup_run () from > /usr/local/lib/libapr-1.so.0 > #1 0x00000000005e3f06 in PlayerHud::~PlayerHud () > #2 0x0000000000000000 in ?? () > > Have you got a solution to help me to find what is the problem ? > Thanks in advance. > > -- > Best regards, > Loïc BLOT, > UNIX systems, security and network engineer > http://www.unix-experience.fr > > > >
