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

Asterisk Bug Tracker noreply at bugs.digium.com
Sat Apr 17 04:23:06 CDT 2010


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 04:23 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0120558) sergee (reporter) - 2010-04-17 04:23
 https://issues.asterisk.org/view.php?id=16608#c120558 
---------------------------------------------------------------------- 
> 2) No, you see RTP _sent_ from Asterisk, but in certain cases (most?),
you aren't _receiving_ RTP. That's what's causing the timeout.

Probably i don't understand something again, here are an output from
tshark for 2 calls which was droped by asterisk due to false-positive on
rtptimeout.


Call-leg 'A' (Zoiper -> Asterisk), 2 seconds before disconnect:

 38.194732 10.10.10.197 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0xC7E1A4D6, Seq=27074, Time=1632192850
 38.212472 10.10.10.197 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0xC7E1A4D6, Seq=27075, Time=1632193010
 38.215000 10.10.10.207 -> 10.10.10.197 RTP PT=ITU-T G.711 PCMA,
SSRC=0x21A9E0DB, Seq=35190, Time=586537724
 38.230463 10.10.10.197 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0xC7E1A4D6, Seq=27076, Time=1632193170
 38.235990 10.10.10.207 -> 10.10.10.197 RTP PT=ITU-T G.711 PCMA,
SSRC=0x21A9E0DB, Seq=35191, Time=586537884
 38.250200 10.10.10.197 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0xC7E1A4D6, Seq=27077, Time=1632193330
 38.256975 10.10.10.207 -> 10.10.10.197 RTP PT=ITU-T G.711 PCMA,
SSRC=0x21A9E0DB, Seq=35192, Time=586538044
 38.273687 10.10.10.197 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0xC7E1A4D6, Seq=27078, Time=1632193490

 - as far as i understand RTP flows in both directions.


Call-leg 'B' (Asterisk -> Cisco AS5350), 2 seconds before disconnect:


 36.079551 10.10.10.219 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0x1EB3E0DB, Seq=63721, Time=1467799745
 36.100539 10.10.10.219 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0x1EB3E0DB, Seq=63722, Time=1467799905
 36.104070 10.10.10.207 -> 10.10.10.219 RTP PT=ITU-T G.711 PCMA,
SSRC=0xDEBBC5EC, Seq=27226, Time=987187368
 36.116559 10.10.10.207 -> 10.10.10.219 RTP PT=ITU-T G.711 PCMA,
SSRC=0xDEBBC5EC, Seq=27227, Time=987187528
 36.121527 10.10.10.219 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0x1EB3E0DB, Seq=63723, Time=1467800065
 36.135547 10.10.10.207 -> 10.10.10.219 RTP PT=ITU-T G.711 PCMA,
SSRC=0xDEBBC5EC, Seq=27228, Time=987187688
 36.142515 10.10.10.219 -> 10.10.10.207 RTP PT=ITU-T G.711 PCMA,
SSRC=0x1EB3E0DB, Seq=63724, Time=1467800225


 - as far as i understand RTP flows in both directions.

So i have a question - why you think that Asterisk is not _receiving_ RTP? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-17 04:23 sergee         Note Added: 0120558                          
======================================================================




More information about the asterisk-bugs mailing list