[asterisk-bugs] [Asterisk 0016321]: [patch] [regression] asterisk deadlocks and calls will stop queueing.
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Jan 19 12:46:12 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16321
======================================================================
Reported By: valon24
Assigned To: jpeeler
======================================================================
Project: Asterisk
Issue ID: 16321
Category: Channels/chan_agent
Reproducibility: random
Severity: major
Priority: normal
Status: closed
Target Version: 1.4.30
Asterisk Version: SVN
JIRA: SWP-460
Regression: Yes
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2009-11-25 11:31 CST
Last Modified: 2010-01-19 12:46 CST
======================================================================
Summary: [patch] [regression] asterisk deadlocks and calls
will stop queueing.
Description:
Our system will go fine for days processing calls queueing them and then
deliver the calls to agents, we will then see the problem at random, it
will happen sometimes every 3 or 4 days and then sometimes 3 times in one
day.
The problem will force us to restart asterisk.
A call will come into the inbound route and then the queue application is
called.
after the queue application is call there is just dead air and nothing
more will happen with that call. Once it happens no other calls will be
processed they will just keep hitting the queue application and go to
silence.
Normally in the CLI we will see something like:
[Nov 23 14:35:18] VERBOSE[4930] logger.c: -- Executing
[909 at from-internal:18] Queue("SIP/192.168.6.132-c8170bc0",
"909|t|1712|1712") in new stack
[Nov 23 14:35:18] VERBOSE[4930] logger.c: -- Started music on hold,
class 'acc_1', on SIP/192.168.6.132-c8170bc0
After the system deadlocks we will only see:
[Nov 23 14:36:14] VERBOSE[5009] logger.c: -- Executing
[903 at from-internal:18] Queue("SIP/192.168.6.132-c8114300",
"903|t|1709|1709") in new stack
I have will attach the output of core show locks and so everyone can see
the full log but this is normally what we see each time we see the issue
This happened 3 times yesterday:
=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 1097607488 (do_devstate_changes started at [ 363]
devicestate.c ast_device_state_engine_init())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (devicestate.c): MUTEX
289 do_state_change
&(&devstate_cbs)->lock 0x75e390 (1)
=== ---> Lock https://issues.asterisk.org/view.php?id=1 (chan_agent.c): MUTEX
304 agent_devicestate_cb
&(&agents)->lock 0x2aaaba9a24f0 (1)
=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=2
(chan_agent.c): MUTEX 313
agent_devicestate_cb &p->lock 0x2aaaaceecd80 (1)
=== --- ---> Locked Here: chan_agent.c line 498 (agent_read)
=== -------------------------------------------------------------------
===
=== Thread ID: 1106180416 (session_do started at [ 2522]
manager.c accept_thread())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (manager.c): RDLOCK 2281
process_message &actionlock
0x76b720 (1)
=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=1
(app_queue.c): MUTEX 4781
manager_queues_status &(&queues)->lock 0x2aaab6129bd0 (1)
=== --- ---> Locked Here: app_queue.c line 2842 (try_calling)
=== -------------------------------------------------------------------
===
=== Thread ID: 1112938816 (pbx_thread started at [ 2623] pbx.c
ast_pbx_start())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (channel.c): MUTEX 2061
__ast_read &chan->lock 0x2768a68
(1)
=== ---> Lock https://issues.asterisk.org/view.php?id=1 (chan_agent.c): MUTEX
498 agent_read &p->lock
0x2aaaaceecd80 (1)
=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=2
(chan_agent.c): MUTEX 1669 agent_logoff
&(&agents)->lock 0x2aaaba9a24f0 (1)
=== --- ---> Locked Here: chan_agent.c line 304 (agent_devicestate_cb)
=== -------------------------------------------------------------------
===
=== Thread ID: 1129191744 (pbx_thread started at [ 2623] pbx.c
ast_pbx_start())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (app_queue.c): MUTEX
2842 try_calling &(&queues)->lock
0x2aaab6129bd0 (1)
=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=1
(chan_agent.c): MUTEX 1456 agent_request
&(&agents)->lock 0x2aaaba9a24f0 (1)
=== --- ---> Locked Here: chan_agent.c line 304 (agent_devicestate_cb)
=== -------------------------------------------------------------------
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0014091 autologoff does not work
======================================================================
----------------------------------------------------------------------
(0116927) svnbot (reporter) - 2010-01-19 12:46
https://issues.asterisk.org/view.php?id=16321#c116927
----------------------------------------------------------------------
Repository: asterisk
Revision: 241314
_U trunk/
U trunk/channels/chan_agent.c
------------------------------------------------------------------------
r241314 | jpeeler | 2010-01-19 12:46:11 -0600 (Tue, 19 Jan 2010) | 20
lines
Merged revisions 241227 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r241227 | jpeeler | 2010-01-19 11:22:18 -0600 (Tue, 19 Jan 2010) | 13
lines
Fix deadlock in agent_read by removing call to agent_logoff.
One must always lock the agents list lock before the agent private.
agent_read
locks the private immediately, so locking the agents list lock is not an
option (which is what agent_logoff requires). Because agent_read already
has access to the agent private all that is necessary is to do the
required
hanging up that agent_logoff performed.
(closes issue https://issues.asterisk.org/view.php?id=16321)
Reported by: valon24
Patches:
bug16321.patch uploaded by jpeeler (license 325)
........
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=241314
Issue History
Date Modified Username Field Change
======================================================================
2010-01-19 12:46 svnbot Checkin
2010-01-19 12:46 svnbot Note Added: 0116927
======================================================================
More information about the asterisk-bugs
mailing list