Summary:ASTERISK-30064: pbx: iax2 switch causes crash due to deadlock and assertion
Reporter:N A (InterLinked)Labels:
Date Opened:2022-05-16 05:15:28Date Closed:2022-06-06 17:42:48
Status:Closed/CompleteComponents:Channels/chan_iax2 PBX/General
Versions:18.9.0 Frequency of
Environment:Debian 10Attachments:( 0) uforrqchjv.txt
Description:Attempting to use "switch" with IAX2 causes a crash.

I am marking this major considering there is a major problem with the dialplan itself.

[2022-05-16 10:10:34] NOTICE[7956]: chan_iax2.c:8173 authenticate_verify: Call Terminated, Incoming call is unencrypted while force encrypt is enabled.
[2022-05-16 10:10:34] NOTICE[7956]: chan_iax2.c:11300 socket_process_helper: Host REDACTED:4569 failed to authenticate as phreaknet
[2022-05-16 10:10:34] DEBUG[8015][C-00000001]: channel.c:3069 ast_waitfor_nandfds: Thread LWP 8015 is blocking 'REDACTED', already blocked by thread LWP 8008 in procedure ast_waitfor_nandfds
[2022-05-16 10:10:34] ERROR[8015][C-00000001]: channel.c:3069 ast_waitfor_nandfds: FRACK!, Failed assertion 0 (0)
[2022-05-16 10:10:34] ERROR[8015][C-00000001]:   Got 17 backtrace records
# 0: [0x55b6f649c4d1] asterisk utils.c:2727 __ast_assert_failed()
# 1: [0x55b6f633e320] asterisk utils.h:728 _ast_assert()
# 2: [0x55b6f6347d49] asterisk channel.c:3069 ast_waitfor_nandfds()
# 3: [0x7fb216deddfe] chan_iax2.so chan_iax2.c:14305 find_cache()
# 4: [0x7fb216dee103] chan_iax2.so chan_iax2.c:14368 iax2_exists()
# 5: [0x55b6f63e6d0b] asterisk pbx.c:2752 pbx_find_extension()
# 6: [0x55b6f63e7776] asterisk pbx.c:2895 pbx_extension_helper()
# 7: [0x55b6f63ebd33] asterisk pbx.c:4181 ast_exists_extension()
# 8: [0x7fb2174061c7] app_stack.so app_stack.c:659 gosub_exec()
# 9: [0x55b6f63ff3d5] asterisk pbx_app.c:492 pbx_exec()
#10: [0x55b6f63e7bc3] asterisk pbx.c:2947 pbx_extension_helper()
#11: [0x55b6f63ebecc] asterisk pbx.c:4206 ast_spawn_extension()
#12: [0x55b6f63ecc5b] asterisk pbx.c:4380 __ast_pbx_run()
#13: [0x55b6f63ee604] asterisk pbx.c:4705 pbx_thread()
#14: [0x55b6f64995f6] asterisk utils.c:1572 dummy_start()
#15: [0x7fb238832fa3] libpthread.so.0 pthread_create.c:487 start_thread()
#16: [0x7fb2382c6eff] libc.so.6 clone.S:97 clone()
Comments:By: Asterisk Team (asteriskteam) 2022-05-16 05:15:30.386-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: N A (InterLinked) 2022-05-16 05:15:50.896-0500

Core dump attached

By: Joshua C. Colp (jcolp) 2022-05-16 05:19:24.423-0500

"major problem with the dialplan itself" is an exaggeration. The major problem is the combination of it and chan_iax2 seemingly, using functionality that probably noone has used in years.

By: N A (InterLinked) 2022-05-16 05:22:43.199-0500

It does seem this may be similar to what you mentioned the other day: CHECK_BLOCKING(c[x]);is the assertion that failed, and we see that a thread in autoservice is blocked by that thread.

By: Joshua C. Colp (jcolp) 2022-05-16 05:25:02.388-0500

Yes, because long ago the pbx core code was changed to start/stop autoservice automatically when invoking switches so that frames didn't just pile up. It is likely chan_iax2 was never touched/updated to account for this.

By: N A (InterLinked) 2022-05-16 05:30:17.864-0500

Hmm... so that's what this is attempting to do? "Autoservice" the channel i.e. process frames in a similar way?


It would seem that should be removed then to fix this. I'm not sure what I'd replace it with though.

By: N A (InterLinked) 2022-05-16 05:33:14.477-0500

To rephrase, I mean w/r/t to the channel, o/w it seems just ast_poll on the pipe might be sufficient, but presumably we do need to know if the channel has hung up, even without autoservicing.

By: Joshua C. Colp (jcolp) 2022-05-16 05:33:51.057-0500

I don't know that code, and I'm not going to spend time on it.

By: Friendly Automation (friendly-automation) 2022-06-06 17:42:49.321-0500

Change 18599 merged by Kevin Harwell:
chan_iax2: Prevent deadlock due to duplicate autoservice.


By: Friendly Automation (friendly-automation) 2022-06-06 17:44:23.267-0500

Change 18564 merged by Kevin Harwell:
chan_iax2: Prevent deadlock due to duplicate autoservice.


By: Friendly Automation (friendly-automation) 2022-06-07 12:05:47.991-0500

Change 18598 merged by Kevin Harwell:
chan_iax2: Prevent deadlock due to duplicate autoservice.


By: Friendly Automation (friendly-automation) 2022-06-07 12:06:13.811-0500

Change 18597 merged by Kevin Harwell:
chan_iax2: Prevent deadlock due to duplicate autoservice.