On Fri, 9 Oct 2015 11:03:10 -0400, Timothy Bish <tabish...@gmail.com> wrote:
>On 10/09/2015 10:56 AM, spamtrap wrote: >> On Fri, 9 Oct 2015 10:49:51 -0400, Timothy Bish >> <tabish...@gmail.com> wrote: >> >>> On 10/09/2015 10:37 AM, spamtrap wrote: >>>> On Mon, 21 Sep 2015 15:34:17 +0100, spamtrap >>>> <nospam.1.friedbad...@spamgourmet.com> wrote: >>>> >>>>> ActiveMQ-CPP 3.9.0 >>>>> >>>>> A program is blocking waiting for a lock: >>>>> >>>>> #0 0x000000367980b5bc in pthread_cond_wait@@GLIBC_2.3.2 () >>>>> from /lib64/libpthread.so.0 >>>>> #1 0x00007fcab6c6c006 in (anonymous namespace)::doMonitorEnter ( >>>>> monitor=0x26f63b0, thread=0x2605960) >>>>> at decaf/internal/util/concurrent/Threading.cpp:662 >>>>> #2 0x00007fcab6cf345b in decaf::util::concurrent::Lock::lock ( >>>>> this=0x7fffe1a00890) at decaf/util/concurrent/Lock.cpp:54 >>>>> #3 0x00007fcab6cf3575 in decaf::util::concurrent::Lock::Lock ( >>>>> this=<value optimized out>, object=<value optimized out>, >>>>> intiallyLocked=<value optimized out>) at >>>>> decaf/util/concurrent/Lock.cpp:32 >>>>> #4 0x00007fcab69f2293 in >>>>> activemq::core::FifoMessageDispatchChannel::stop ( >>>>> this=0x26c2c50) at >>>>> activemq/core/FifoMessageDispatchChannel.cpp:123 >>>>> >>>>> How can I find out what is holding onto this lock? >>>> I could really do with some help here. I am trying to close a >>>> consumer and it hangs forever. >>> Your best bet is to create a test case that reproduces the problem. A >>> stack trace from one thread is not enough to even guess what is going on >>> in your application here so it would be hard for anyone to offer any >>> meaningful help. >> This is not easy because it's very difficult to reproduce the problem >> and I'm really not very sure what triggers it, but it does happen on a >> client's system. In general terms is it safe to close a consumer >> object at any time? And how can I find out what is holding onto the >> lock? >> >> >> >> >You can use GDB to view the threads and see what is going on. I have ;-) > Could be >your application in hung in an onMessage call and cannot complete the >close call until that completes but that is just speculation. IIRC all the threads were waiting in pthread_cond_wait or similar (and there are a very large number of threads in this application). It shouldn't be hanging in an onMessage call since this method hands off the processing to other threads. I don't know when I'll be able to reproduce it again. If I can find out which thread is holding onto the lock that would be a start.
