[asterisk-bugs] [Asterisk 0015314]: [patch] Seg fault in chan_local - local_pvt_destroy
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Aug 18 07:36:23 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=15314
======================================================================
Reported By: sroberts
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 15314
Category: Channels/chan_local
Reproducibility: unable to reproduce
Severity: crash
Priority: normal
Status: acknowledged
Target Version: 1.4.28
Asterisk Version: 1.4.22
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-06-11 04:50 CDT
Last Modified: 2009-08-18 07:36 CDT
======================================================================
Summary: [patch] Seg fault in chan_local - local_pvt_destroy
Description:
This is the same issue as 14780. We also use SNOM phones (300s and 320s)
however these extensions are not connected to the server on which Asterisk
crashed. The crash occurred on the queue server.
A backtrace of the crash has been attached.
The crash here occurred when callfile finished execution. We use callfiles
to pause/unpause the agents. The local_pvt being freed is not null:
(gdb) frame 2
https://issues.asterisk.org/view.php?id=2 0x002dd837 in local_pvt_destroy
(pvt=0xa23e928) at chan_local.c:159
159 free(pvt);
(gdb) p pvt
$1 = (struct local_pvt *) 0xa23e928
(gdb) p *pvt
$2 = {lock = {mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0,
__m_kind = 1, __m_lock = {__status = 0, __spinlock = 0}}, track = 1, file =
{0x2e0f08 "chan_local.c", 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
lineno = {158, 0, 0, 0, 0, 0, 0, 0, 0, 0}, reentrancy = 0, func = {0x2e0fbe
"local_pvt_destroy", 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, thread =
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, reentr_mutex = {__m_reserved = 0, __m_count
= 0, __m_owner = 0x0, __m_kind = 1, __m_lock = {__status = 0, __spinlock =
0}}}, flags = 16, context = "vital-out", '\0' <repeats 70 times>, exten =
"*\000vital-out\000n", '\0' <repeats 66 times>, reqformat = 64, owner =
0x0, chan = 0x0, u_owner = 0xa2234c8, u_chan = 0xa1c3500, list = {next =
0x0}}
Due to the fact that our queue servers are so busy I cannot simply upgrade
it to a newer version (this one in particular handles around 10000 calls
per day) unless I know a version is stable. I've tested 1.4.25 and it
proved horrendously unstable (deadlocks and seg faults).
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0014780 Asterisk abort (signal 6) in local_pvt_...
======================================================================
----------------------------------------------------------------------
(0109206) davidw (reporter) - 2009-08-18 07:36
https://issues.asterisk.org/view.php?id=15314#c109206
----------------------------------------------------------------------
OK. The context is:
Incoming SIP call bridged via Dial to
Problem local channel, which is executing Queue
Queue has been autoanswered by a non-callback Agent
The Agent is owned by another SIP channel.
The CTI has initiated a Park action specifying the incoming SIP call's
channel, an effectively infinite timeout, and a channel known to exist as
the return channel, which is never intended to be used.
This is the verbose trace leading up to the invalid lock:
[2009-08-13 14:48:52.936] VERBOSE[4109] res_musiconhold.c: -- Started
music on hold, class 'default', on SIP/192.168.71.115-b7406a48
SIP/192.168.71.115-b7406a48 is the incoming SIP call
[2009-08-13 14:48:52.936] VERBOSE[4109] features.c: == Parked
SIP/192.168.71.115-b7406a48 on 701 (lot default). Will timeout back to
extension [default] 6050, 50013 in 2000000 seconds
[2009-08-13 14:48:52.936] VERBOSE[4109] pbx.c: -- Added extension
'701' prio
rity 1 to parkedcalls (0x87dd420)
[2009-08-13 14:48:52.937] VERBOSE[4173] res_musiconhold.c: -- Started
music on hold, class 'default', on SIP/sip2-08888cc8
SIP/sip2-08888cc8 is the agent.
[2009-08-13 14:48:52.939] VERBOSE[4173] pbx.c: == Spawn extension
(xxxxxxx, xxxxxx, 8) exited non-zero on 'Local/xxxxxx at xxxxx-b1b8;2'
This is the exit for the Queue application.
The only parameter on the Queue application was "r".
(The local channel is in the chain, because, some time before I got
involved with the project, it was discovered that, without it, transferring
the caller caused the agent to logout.)
Issue History
Date Modified Username Field Change
======================================================================
2009-08-18 07:36 davidw Note Added: 0109206
======================================================================
More information about the asterisk-bugs
mailing list