[asterisk-bugs] [Asterisk 0012376]: Asterisk becomes unresponsive after locking 1.4.19
noreply at bugs.digium.com
noreply at bugs.digium.com
Sat May 17 06:08:13 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12376
======================================================================
Reported By: DougUDI
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 12376
Category: General
Reproducibility: sometimes
Severity: crash
Priority: normal
Status: feedback
Asterisk Version: 1.4.19-rc3
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 04-07-2008 09:26 CDT
Last Modified: 05-17-2008 06:08 CDT
======================================================================
Summary: Asterisk becomes unresponsive after locking 1.4.19
Description:
We are runing a high load system using 1.4.19 and have times where asterisk
becomes completely unresponsive and will not allow any incoming or outgoing
calls to or from the system. After a "core show channels" there is no end
channel count and the CLI will become completely unresponsive. I have
attached "core show locks" output.
======================================================================
----------------------------------------------------------------------
destiny6628 - 05-17-08 06:08
----------------------------------------------------------------------
Had not tested with exactly 116038 revision but have patch the chan_local.c
which was mentioned by russell as
Repository: asterisk
Revision: 116038
U branches/1.4/channels/chan_local.c
------------------------------------------------------------------------
r116038 | russell | 2008-05-13 16:12:25 -0500 (Tue, 13 May 2008) | 24
lines
Fix a deadlock involving channel autoservice and chan_local that was
debugged
and fixed by mmichelson and me.
We observed a system that had a bunch of threads stuck in
ast_autoservice_stop().
The reason these threads were waiting around is because this function
waits to
ensure that the channel list in the autoservice thread gets rebuilt before
the
stop() function returns. However, the autoservice thread was also locked,
so
the autoservice channel list was never getting rebuilt.
The autoservice thread was stuck waiting for the channel lock on a local
channel.
However, the local channel was locked by a thread that was stuck in the
autoservice
stop function.
It turned out that the issue came down to the local_queue_frame() function
in
chan_local. This function assumed that one of the channels passed in as
an
argument was locked when called. However, that was not always the case.
There
were multiple cases in which this channel was not locked when the function
was
called. We fixed up chan_local to indicate to this function whether this
channel
was locked or not. The previous assumption had caused local_queue_frame()
to
improperly return with the channel locked, where it would then never get
unlocked.
But the problem remains same as before .
Please suggests .
Issue History
Date Modified Username Field Change
======================================================================
05-17-08 06:08 destiny6628 Note Added: 0086970
======================================================================
More information about the asterisk-bugs
mailing list