[asterisk-dev] [Code Review] [patch] Use of MASTER_CHANNEL causes a race condition ending in a deadlock among channels

[Russell Bryant]

On Tue, 2011-03-01 at 02:48 -0800, Kirill Katsnelson wrote:
> On 110226 0527, Russell Bryant wrote:
> > Sure enough.  You're right.  Score another for peer review!
> 
> FWIW, the horrible persistent deadlock #28643 that forced us to back out 
> to 1.6 *is* indicating that the monitor thread is holding a channel lock 
> and is blocked obtaining another channel's lock in MASTER_CHANNEL's 
> ast_channel_get_by_name() call. I do not understand the present issue 
> well enough, and am going to say something as stupid as I always do, but 
> it seems to me that if that other channel was calling MASTER_CHANNEL at 
> the same time, the first class deadlock would indeed occur.
> 
> I have no clear idea why does handle_incoming() write to 
> MASTER_CHANNEL() on the sip monitor thread, but it does.
> 
> This is the stack of the thread

<snip>

Yes, this is part of the deadlock we are seeing as well.  The thread you
are pointing to is blocking waiting on a channel lock.

> === --- ---> Locked Here: channel.c line 3636 (__ast_read)

It says it's locked in a thread that called ast_read().  What is that
thread blocking on, though?

By the way, which issue are you referring to?  #28643 isn't a valid
mantis issue number.

-- 
Russell Bryant
Digium, Inc.   |   Engineering Manager, Open Source Software
445 Jan Davis Drive NW    -     Huntsville, AL 35806  -  USA
www.digium.com  -=-  www.asterisk.org -=- blogs.asterisk.org