[asterisk-bugs] [Asterisk 0016767]: [patch] Deadlock between handle_request_do and do_devstate_changes

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16767 
====================================================================== 
Reported By:                lmsteffan
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   16767
Category:                   Channels/chan_sip/General
Reproducibility:            unable to reproduce
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
JIRA:                       SWP-869 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 238602 
Request Review:              
====================================================================== 
Date Submitted:             2010-02-03 20:47 CST
Last Modified:              2010-02-23 23:06 CST
====================================================================== 
Summary:                    [patch] Deadlock between handle_request_do and
do_devstate_changes
Description: 
title says it all :-)
====================================================================== 

---------------------------------------------------------------------- 
 (0118437) lmsteffan (reporter) - 2010-02-23 23:06
 https://issues.asterisk.org/view.php?id=16767#c118437 
---------------------------------------------------------------------- 
After applying your patch Asterisk worked for one day and a half, then was
subjected to another deadlock. I include the result of "core show locks"
(after purging the non-relevant parts). The deadlock is obvious between the
first and the fourth thread. One funny thing is that the fourth thread is
said to be waiting for lock#0  but has gone on to seize other locks,
including those that create the deadlock.

I can't be sure that this deadlock has the same cause as the previous one,
but to my untrained eye it sure looks like it could... If that were not the
case I can submit another bug report. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-23 23:06 lmsteffan      Note Added: 0118437                          
======================================================================