[Home]

Summary:ASTERISK-19386: Channel group not released after a channel has been Chanspy'd upon
Reporter:laszlovl (lvl)Labels:
Date Opened:2012-02-18 10:38:58.000-0600Date Closed:2012-02-22 15:53:05.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_chanspy
Versions:1.8.9.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS 6, 64bitAttachments:( 0) backtrace-threads-after.txt
Description:We're experiencing an issue where a channel group isn't released from a hungup channel, when a Chanspy has been done on that channel. Similar issues are described in ASTERISK-17515 and ASTERISK-17767, but since one of those issues is considered fixed, and I can't reproduce the problem with the dialplan from the other issue, I'm opening up a new report.

The issue occurs under the following circumstances:

1) Through a local channel, an agent is talking to a queue caller
2) Another user starts a Chanspy on this local channel
3) The chanspy is hung up
4) Then, the local channel is hung up

After this, a 'group show channels' will keep on listing the local channel for eternity, even though the channel is in fact hungup and the channel no longer appears in 'core show channels'.

The issue does *not* occur under the following circumstances:

- If the agent hangs up before the chanspy channel hangs up
- If musiconhold is playing on the local channel during the period the channel is chanspy'd upon
- If asterisk is compiled with DEBUG_THREADS on (if this sounds weird, I doublechecked this a couple of times: the issue was reproducable every single time with a regular asterisk, but when i compiled a DEBUG_THREADS version to gather a core show locks, it was impossible to reproduce it anymore)

Stripped verbose log (Local/123@phones/n is a queue member receiving a queue call here):
{quote}
VERBOSE[10681] pbx.c:     -- Executing [123@phones:1] Gosub("Local/123@phones-5a31;2", "callphone,s,1(123)") in new stack
VERBOSE[10681] pbx.c:     -- Executing [s@callphone:3] Set("Local/123@phones-5a31;2", "GROUP()=123") in new stack
...
VERBOSE[11821] app_chanspy.c:   == Spying on channel Local/123@phones-5a31;1
NOTICE[11821] app_chanspy.c: Attaching SIP/phone-000025e9 to Local/123@phones-5a31;1
VERBOSE[11821] app_chanspy.c:   == Done Spying on channel Local/123@phones-5a31;1
VERBOSE[11821] pbx.c:   == Spawn extension (fromlocal, *4, 8) exited non-zero on 'SIP/phone-000025e9'
...
VERBOSE[10681] pbx.c:   == Spawn extension (callphone, s, 19) exited non-zero on 'Local/123@phones-5a31;2'
{quote}
Afterwards:
{quote}
dev*CLI> group show channels
Channel                    Group                 Category            
Local/123@phones-5a31;2    123                   (default)  
{quote}
Comments:By: laszlovl (lvl) 2012-02-18 10:41:39.884-0600

Attached is a backtrace.

0x7fa5813fd700 is the only thread that did not yet exist before the call+callspy was done
By: laszlovl (lvl) 2012-02-18 12:31:42.096-0600

Looks like this might be fixed by r352957: "Audit of ao2_iterator_init() usage for v1.8." I'll update here when I can confirm.
By: laszlovl (lvl) 2012-02-22 15:53:05.522-0600

After running with r352957 in production for a couple of days, I can confirm with near certainty that this fixes the issue. Thanks!