[asterisk-bugs] [Asterisk 0016608]: [patch] Deadlock on &(&channels)->lock
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Apr 15 02:41:49 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: ready for testing
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-15 02:41 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.
======================================================================
----------------------------------------------------------------------
(0120444) sergee (reporter) - 2010-04-15 02:41
https://issues.asterisk.org/view.php?id=16608#c120444
----------------------------------------------------------------------
just a thoughts:
1. without your first patch - rtptimeoput wasn't triggered. I checked it
just now - with clean asterisk 1.6.0 r237060, problem with false-positives
on rtptimeouts - doesn't exist.
2. i can see RTP from both peers on asterisk-host with wireshark. Also i
can see RTP in Asterisk with "rtp debug"
Sent RTP P2P packet to 1.1.1.1:16542 (type 08, len 000160)
Sent RTP P2P packet to 2.2.2.2:8000 (type 08, len 000160)
Sent RTP P2P packet to 1.1.1.1:16542 (type 08, len 000160)
Sent RTP P2P packet to 2.2.2.2:8000 (type 08, len 000160)
Sent RTP P2P packet to 1.1.1.1:16542 (type 08, len 000160)
Sent RTP P2P packet to 2.2.2.2:8000 (type 08, len 000160)
May be it has something to do with bridging technology engaged in this
call:
-- Packet2Packet bridging SIP/1010-00000002 and SIP/voipgw4-00000003
3. canreinvite=no is configured for both peers
Issue History
Date Modified Username Field Change
======================================================================
2010-04-15 02:41 sergee Note Added: 0120444
======================================================================
More information about the asterisk-bugs
mailing list