[asterisk-bugs] [Asterisk 0016608]: [patch] Deadlock on &(&channels)->lock

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16608 
====================================================================== 
Reported By:                sergee
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   16608
Category:                   Channels/General
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     feedback
Target Version:             1.6.0.28
Asterisk Version:           SVN 
JIRA:                       SWP-732 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!): 237060 
Request Review:              
====================================================================== 
Date Submitted:             2010-01-14 15:04 CST
Last Modified:              2010-04-17 11:30 CDT
====================================================================== 
Summary:                    [patch] Deadlock on &(&channels)->lock
Description: 
I've got 2 deadlocks in 3 days. It happens in a peak hours, with more then
a hundred calls in the system.

I've got 2 files 1 with "core show locks" - from the first deadlock (the
day before yesterday), second file - with output from gdb (intho thread,
thread apply all bt, thread apply all bt full) - from today's deadlock.
====================================================================== 

---------------------------------------------------------------------- 
 (0120561) sergee (reporter) - 2010-04-17 11:30
 https://issues.asterisk.org/view.php?id=16608#c120561 
---------------------------------------------------------------------- 
Ok, i found out the reason of false-positives for rtp-timeout. As i said
before, false-positives for rtptimeouts happens for calls which are bridged
with 'Packet2Packet bridging'.

The reason is your code, added to sip_read(): 


	if (fr == &ast_null_frame) {
		sip_pvt_unlock(p);
		return fr;
	}

it was added right before:

p->lastrtprx = time(NULL);

So, if sip_rtp_read(ast, p, &faxdetected) returns &ast_null_frame -
p->lastrtprx is never updated (with your patch).

But, with 'Packet2Packet bridging', sip_rtp_read() always returns
&ast_null_frame, here is a code from ast_rtp_read():

        if ((bridged = ast_rtp_get_bridged(rtp)) &&
!bridge_p2p_rtp_write(rtp, bridged, rtpheader, res, hdrlen)) {
                return &ast_null_frame;
        }


tilghman, i suggest a simple modification of your last patch (patch
uploaded) - please review it. If you don't mind against this modification -
 we could proceed with original problem - i will organize testing. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-17 11:30 sergee         Note Added: 0120561                          
======================================================================