Summary:	ASTERISK-30057: channels: assertion in ast_waitfor_nandfds
Reporter:	N A (InterLinked)	Labels:
Date Opened:	2022-05-11 04:43:55	Date Closed:	2022-05-13 08:16:17
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Core/Channels
Versions:	18.9.0	Frequency of Occurrence	One Time
Related Issues:
Environment:	Debian 10	Attachments:	( 0) hyxzyakpsj.txt
Description:	Assertion failure in ast_waitfor_nandfds full.txt backtrace attached.
Comments:	By: Asterisk Team (asteriskteam) 2022-05-11 04:43:56.064-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Joshua C. Colp (jcolp) 2022-05-11 04:51:55.298-0500 The line numbers in the backtrace don't match 18.9.0, so I can't actually see what assertion was triggered. I can only guess based on the backtrace it's because the channel seems to also be in autoservice at the same time - which you can't do. Two threads can't hold ownership over the same channel at the same time. There's also no details here about the events leading up to this or what was going on. A debug log would be needed. By: N A (InterLinked) 2022-05-12 10:38:55.057-0500 Sorry, which line numbers? Line 726 in utils.h is here: {noformat} static void force_inline _ast_assert(int condition, const char *condition_str, const char *file, int line, const char *function) {        if (__builtin_expect(!condition, 1)) {                __ast_assert_failed(condition, condition_str, file, line, function);        } } {noformat} Line 3069 of channel.c is: CHECK_BLOCKING(c[x]); By: Joshua C. Colp (jcolp) 2022-05-12 10:42:16.018-0500 Then the reason is exactly as I surmised in my initial response. Two threads have ownership over the channel, which is not allowed. Why that is - I can't say without the information I mentioned. By: N A (InterLinked) 2022-05-12 10:55:37.735-0500 Unfortunately, that seems to be all I have to go off at the moment. This hasn't happened before, so it seems unlikely it would happen again soon, but I'll watch for it. I also took a look at the autoservice APIs, and they don't seem to currently log (debug) when autoservice is started on the channel. What would be helpful is a way to trace how autoservice got started in the first place, since looking at the dialplan I don't see how it could have. However even with debug it does not seem that information would be present. Should a debug be added with the current execution location when a channel goes into autoservice? By: Joshua C. Colp (jcolp) 2022-05-12 11:14:59.247-0500 Possibly? The debug was also to give insight into what exactly was going on at the time, not the channel going into autoservice exactly. By: Joshua C. Colp (jcolp) 2022-05-13 08:16:17.828-0500 I'm suspending this for now since there's nothing really actionable with the given information.