Summary:ASTERISK-17767: Channel Group exists for nonexistent channel (didn't clear out properly)
Reporter:WRP (wrp)Labels:
Date Opened:2011-04-28 11:13:30Date Closed:2011-08-31 09:17:03
Versions:1.8.3 Frequency of
Environment:Attachments:( 0) backtrace-threads.txt
( 1) backtrace-threads2.txt
( 2) backtrace-threads2-correct.txt
( 3) chan_spy_unref_iterator_good.patch
( 4) chan_spy_unref_iterator.patch
( 5) core-show-locks.txt
Description:A channel group was set and was expected to clear out once the channel closed (as is the default behavior in Asterisk). The channel group, however, did not clear after the channel closed.

We have been unable to remove the channel manually as Asterisk does not provide a means for this (as far as we know), since this is a feature "managed" by Asterisk.

The channel group in question in the "Additional Information" section below is:
SIP/2137-000001d1          2137                  (default)


[root@newast02 asterisk]# asterisk -rx "group show channels"
Channel                    Group                 Category            
SIP/coloCUBE-000000d8      OUT_5                 (default)          
SIP/2137-000001d1          2137                  (default)          
SIP/2225-000002ac          2225                  (default)          
SIP/coloCUBE-000002b4      OUT_5                 (default)          
SIP/2170-000002bd          2170                  (default)          
SIP/2228-000002c3          2228                  (default)          
SIP/2163-000002c9          2163                  (default)          
SIP/2110-000002cb          2110                  (default)          
SIP/2209-000002d5          2209                  (default)          
SIP/2179-000002d8          2179                  (default)          
SIP/2226-000002d9          2226                  (default)          
SIP/2166-000002da          2166                  (default)          
12 active channels

[root@newast02 asterisk]# asterisk -rx "core show channel SIP/2137-000001d1"
SIP/2137-000001d1 is not a known channel

[root@newast02 asterisk]#
Comments:By: Leif Madsen (lmadsen) 2011-05-05 07:32:03

I'm not sure what could be going on here, however I think we should start with a backtrace and 'core show locks'.

Can you get that info and attach it here as a text file? Documentation for getting that information is available here:


The backtrace can still be obtained while Asterisk is running by attaching to the existing process.

By: WRP (wrp) 2011-05-05 11:41:04

Thanks for the response. We have not had the issue since, but I will follow these steps next time that we do.

By: Leif Madsen (lmadsen) 2011-05-10 16:37:00

OK thanks for the follow up. I'm just going to close this issue for now, but please do open it back up if you run into the issue again and can provide some additional information. Thanks!

By: WRP (wrp) 2011-05-10 16:43:30

We actually just had the issue happen again today, the first group/channel being the problem one:

newast02*CLI> group show channels
Channel                    Group                 Category            
SIP/2201-00001699          2201                  (default)          
SIP/2232-0000199a          2232                  (default)          
SIP/2188-000019d4          2188                  (default)          
SIP/2186-000019e1          2186                  (default)          
SIP/2132-000019e3          2132                  (default)          
SIP/2126-000019e9          2126                  (default)          
SIP/2228-000019ea          2228                  (default)          
SIP/2178-000019ef          2178                  (default)          
SIP/2194-000019f3          2194                  (default)          
SIP/2226-000019f7          2226                  (default)          
Local/301914252754485@queuedial-ba4a;1  OUT_1                 (default)          
SIP/2040-000019fd          2040                  (default)          
12 active channels

newast02*CLI> core show channel SIP/2201-00001699
SIP/2201-00001699 is not a known channel

I will attach the two files you requested now.

By: WRP (wrp) 2011-05-10 17:42:48

This just happened again (second time today):

newast02*CLI> group show channels
Channel                    Group                 Category            
SIP/2201-00001699          2201                  (default)       <--- previous uncleared group    
SIP/2232-0000199a          2232                  (default)        <--- new uncleared group (channel no longer exists)
SIP/2178-00001a6b          2178                  (default)          
SIP/2226-00001abd          2226                  (default)          
SIP/2192-00001abf          2192                  (default)          
SIP/coloCUBE-00001ac1      OUT_5                 (default)          
SIP/2233-00001ac6          2233                  (default)          
7 active channels

I've uploaded a new backtrace file. "core show locks" still reports nothing, so I won't upload a second locks output file.

By: WRP (wrp) 2011-05-10 17:46:55

Please disregard "backtrace-threads2.txt" as it is a duplicate of "backtrace-threads.txt". "backtrace-threads2-correct.txt" is the correct file for comment 0134761 (immediately above),

By: WRP (wrp) 2011-05-17 13:19:20

This problem persists in Asterisk 1.8.4

By: Taylor Solazzo (tsolazzo) 2011-05-17 13:24:05

Note: This is happening about 2-3times a week. Our current workaround is to assign the user a new device, which unfortunately ruins their stats.

By: Arkadiusz Malka (yarns) 2011-05-18 11:15:05

I submited similar bug few weeks a go: https://issues.asterisk.org/view.php?id=18929

By: WRP (wrp) 2011-05-18 11:34:00

That certainly sounds like it could be a possibility in our situation as well, as we use chanspy. Hopefully a resolution is found shortly.

By: Marcus Spurkel (mspurkel) 2011-05-25 17:34:10

We have the same problem (on and I can confirm that ChanSpy was used on the line before the channel group was orphaned.

By: Irontec (irontec) 2011-07-26 07:40:51.546-0500

After some digging we've found that the problem was these channels weren't properly released.

Problem was that next_channel in autochan.c uses ast_channel_iterator_next which already adds a ref to the channel. After working with that channel, it is necessary to unref that channel.

This wasn't being done in but it seems to be corrected in trunk, so if you want to do a patch if your version is not properly patched I attached one.

By: Irontec (irontec) 2011-07-26 07:45:27.332-0500

Patch applied in to fix the unref missing after using iterator_next

By: Jonathan Rose (jrose) 2011-08-31 09:17:03.904-0500

That patch seems to come from a commit I made for https://issues.asterisk.org/view.php?id=18742 back in March.

It's been fixed in releases since at the latest.  Closing issue.