[asterisk-bugs] [JIRA] (ASTERISK-25844) app_queue: Ghost channels in "core show channels" output

[Robert Mordec (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233887#comment-233887 ] 

Robert Mordec commented on ASTERISK-25844:
------------------------------------------

Thanks to Reference Count Debugging wiki (https://wiki.asterisk.org/wiki/display/AST/Reference+Count+Debugging) I found the probable culprit. Info from git:

{quote}
SHA-1: 6409e7b11a2310196a9978b30a6b79e2760be592
* app_queue: Crash when transferring

ASTERISK-25185 #close
Reported by: Etienne Lessard

(...)
This patch adds a reference to both the member and caller channels that
extends to the lifetime of the queue'd call, thus making sure the channels
will always exist when retrieving the latest snapshots.

Change-Id: Ic397fa68fb4ff35fbc378e745da9246a7b552128
{quote}

{code:title=app_queue.c|borderStyle=solid}
static struct queue_stasis_data *queue_stasis_data_alloc(struct queue_ent *qe,
		struct ast_channel *peer, struct member *mem, time_t holdstart,
		time_t starttime, int callcompletedinsl)
{

(...)

/*
 * During transfers it's possible for both the member and/or caller
 * channel(s) to not be available. Adding a reference here ensures
 * that the channels remain until app_queue is completely done with
 * them.
 */
queue_data->member_channel = ao2_bump(peer);
queue_data->caller_channel = ao2_bump(qe->chan);
{code}

The added reference holds (optimized away?) local channel which will be destroyed when the call ends.

At this point I don't have a good idea how to fix this without reintroducing ASTERISK-25185. Maybe someone else will have more luck using this additional info.

> app_queue: Ghost channels in "core show channels" output
> --------------------------------------------------------
>
>                 Key: ASTERISK-25844
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25844
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue, Channels/chan_local, Core/Channels
>    Affects Versions: 13.7.2
>         Environment: Debian 8.3 amd64
>            Reporter: Etienne Lessard
>            Severity: Minor
>
> Given I have two 2 SIP users, Alice (SIP/alice) and Bob (SIP/bob)
> Given I have the following queues.conf:
> {noformat}
> [sales]
> strategy = ringall
> member => Local/52 at default
> [wait]
> stategy = ringall
> {noformat}
> Given I have the following extensions.conf
> {noformat}
> [default]
> exten = 50,1,NoOp()
> same  =   n,Queue(sales)
> same  =   n,Hangup()
> exten = 51,1,NoOp()
> same  =   n,Queue(wait)
> same  =   n,Hangup()
> exten = 52,1,NoOp()
> same  =   n,Dial(SIP/bob)
> same  =   n,Hangup()
> exten = 53,1,NoOp()
> same  =   n,Bridge(SIP/alice-00000000)
> same  =   n,Hangup()
> {noformat}
> When Alice calls the 50 extension
> And Bob answers
> Then there is 1 temporary ghost channel "Local/52 at default-00000000;1" that can be seen in the "core show channels concise" output
> When Alice's channel is redirected to the 51 at default extension via the AMI "Redirect" command
> When a "channel originate SIP/bob extension 53 at default" is done
> And Bob answers and is bridged with Alice's channel
> And Alice's channel is hanged up via the AMI "Hangup" command
> Then there are 2 permanent ghost channels in the output of core show channels:
> {noformat}
> el*CLI> core show channels
> Channel              Location             State   Application(Data)             
> Local/52 at default-000 50 at default:1         Up      AppQueue((Outgoing Line))     
> Surrogate/SIP/69jqad 51 at default:1         Down    (None)                        
> 0 active channels
> 0 active calls
> 4 calls processed
> {noformat}
> So this scenario is a bit complex, I've tried finding a simpler one but was not able to. With this scenario, I've been able to produce ghost channels systematically. This impact us because we have an external application (a switchboard application) that use Asterisk in this kind of way.
> The only impact I have found is that the output of "core show channels" becomes less and less useful (for administration purpose) as ghost channels adds up.
> When we try to hangup one of these ghost channels via "channel request hangup", it says "<channel> is not a known channel". It seems like these channels only exists in the stasis cache and not in the ao2_container of channels.



--
This message was sent by Atlassian JIRA
(v6.2#6252)