[asterisk-dev] DEBUG_THREADS and unreleased locks

[Russell Bryant]

Norman Franke wrote:
> I've compiled Asterisk 1.4.17 with DEBUG_CHANNEL_LOCKS, DEBUG_THREADS,
> DETECT_DEADLOCKS, DONT_OPTIMIZE and MALLOC_DEBUG. After running for some
> time, I noticed this. It's happened several times. I do have a
> custom-developed app for call direction.
> 
> === Thread ID: 3061398448 (do_monitor           started at [15638]
> chan_sip.c restart_monitor())
> === ---> Tried and failed to get Lock #0 (channel.c): MUTEX 5012
> ast_channel_trylock &chan->lock 0xb6b7cee8 (4)
> === ---> Lock #1 (channel.c): MUTEX 5012 ast_channel_trylock &chan->lock
> 0xb50032c0 (1)
> 
> I generally think I can ignore the "tried and failed", but it thinks
> it's holding a lock (and for hours.) There are no active channels "core
> show channels" gives 0 active. "sip show channels" also has nothing.
> chan_sip.c:do_monitor seems to only get a channel lock in one place, and
> I can't see how it can exit without unlocking it.

You're right that you can generally ignore the "Tried and failed to get" one.
However, I think we have changed it since then such that it won't keep those
around once the thread has moved on and tried to lock something else.

It is certainly possible that the channel lock that did get acquired was never
released.  One idea that came up recently was adding something so that you can
see how long a lock has been held.  That would help to know for sure ...

Another thing you can do is to not set a breakpoint, but to just get a backtrace
of the SIP monitor thread when you have it in this state.  Then, you can see if
it's somewhere where it makes sense to still be holding a channel lock.

However, I know that there have been multiple related fixes since 1.4.17, so I
would encourage you to go ahead and update to the latest release candidate for
1.4.18 and see if you still have a problem.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.