[asterisk-dev] Possible Deadlock?

[Norman Franke]

On Aug 22, 2008, at 1:00 PM, asterisk-dev-request at lists.digium.com  
wrote:

> Thanks for the report. There are a few peculiarities with the  
> backtrace
> provided. For instance, the trace of thread 21 is not possible since
> ast_mutex_lock does not call ast_mutex_unlock.But I think that's  
> just a fluke
> here because the problem seems legitimate to me.
>
>  To answer your question about how and where thread 32 locks a  
> channel, that's
> done inside of sipsock_read in chan_sip, line 15537.
>
> The 480 response being received does not appear to have anything to  
> do with the
> deadlock, but rather an unsafe locking order used in chan_sip. The  
> proper order,
> if a channel and the channel list lock are needed is to lock the  
> list and then
> the channel, not the other way around.
>
> I would suggest opening a bug report for this on bugs.digium.com so  
> that this
> doesn't end up getting lost in the mail, so to speak. I don't  
> suspect that this
> issue is going to be a particularly easy or quick one to fix, but it  
> is important.
>
> Mark Michelson


Mark,

Thanks for commenting. I also noted those peculiarities, but I figured  
it was either cruft left on the stack or something similar. Like in 32  
ast_cdr_start cannot be in the same stack as the channel lock way  
below that. This is using a 2.6.23-11 kernel.

As for the bug report, based on past experience, they don't support  
modified systems (I've added a non-Digium module), so they refused to  
do anything, hence posting on the list. (Despite the FAQ not stating  
this.)

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com