| 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:30 | Date Closed: | 2011-08-31 09:17:03 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | 1.8.3 | Frequency of Occurrence | |
| Related Issues: | |||
| 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) ****** ADDITIONAL INFORMATION ****** [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: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace 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 1.8.3.2) 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 1.8.2.3 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 1.8.2.3 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 1.8.5.0 at the latest. Closing issue. | ||