Stasis.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7fa284002630 (0)

Did an upgrade yesterday from Asterisk 16.30.0 to Asterisk 18.9.
Everything was running fine for almost 24 hours and then the system started spewing the errors below. Several GB worth in 15 minutes.

I’ll look through other posts to see if anything similiar, but most posts found so far are pretty old.

Thanks,
Andy

[2024-11-03 14:36:45] ERROR[21863] stasis.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7fa284002630 (0)
[2024-11-03 14:36:45] ERROR[21863] : Got 17 backtrace records
# 0: /usr/sbin/asterisk(__ast_assert_failed+0x84) [0x5cf01d]
# 1: /usr/sbin/asterisk() [0x460835]
# 2: /usr/sbin/asterisk(__ao2_trylock+0x64) [0x460c8a]
# 3: /usr/sbin/asterisk(stasis_forward_all+0x1a2) [0x593ba1]
# 4: /usr/lib64/asterisk/modules/res_stasis.so(+0xeb0f) [0x7fa2adcdbb0f]
# 5: /usr/lib64/asterisk/modules/res_stasis.so(+0x12505) [0x7fa2adcdf505]
# 6: /usr/lib64/asterisk/modules/res_stasis.so(+0x1849d) [0x7fa2adce549d]
# 7: /usr/lib64/asterisk/modules/res_stasis.so(+0x1869f) [0x7fa2adce569f]
# 8: /usr/lib64/asterisk/modules/res_stasis.so(+0x152b0) [0x7fa2adce22b0]
# 9: /usr/lib64/asterisk/modules/res_stasis.so(+0x18be4) [0x7fa2adce5be4]
#10: /usr/lib64/asterisk/modules/res_stasis.so(stasis_app_exec+0xc53) [0x7fa2adcd87b3]
#11: /usr/lib64/asterisk/modules/app_stasis.so(+0xb9f) [0x7fa2a5f3db9f]
#12: /usr/sbin/asterisk(pbx_exec+0x11c) [0x544245]
#13: /usr/lib64/asterisk/modules/res_ari_channels.so(+0xb39d) [0x7fa29fd1939d]
#14: /usr/sbin/asterisk() [0x5cc1cd]
#15: /lib64/libpthread.so.0(+0x7ea5) [0x7fa31dff3ea5]
#16: /lib64/libc.so.6(clone+0x6d) [0x7fa31d0928dd]

On Sunday 03 November 2024 at 20:59:43, blkrckz28 via Asterisk Community
wrote:

Did an upgrade yesterday from Asterisk 16.30.0 to Asterisk 18.9.

Why?

Asterisk 18 has just gone into “security fix only” status:

https://docs.asterisk.org/About-the-Project/Asterisk-Versions/

Antony.


Users don’t know what they want until they see what they get.

                                               Please reply to the list;
                                                     please *don't* CC me.

I tried going to 20 LTS but it always failed, so I did a restore, upgraded to 18 LTS and that worked… I was waiting to ensure that the system was stable before going to 20LTS… That would have been tomorrow’s task.
Waiting to ensure that it is stable, then take those steps to the production system

Don’t mean to hijack the thread but thought I’ll ask. I saw this comment about Asterisk 18’s security-fixes-only status and was wondering if it is really so bad if every thing is working fine in 18.x.

We’re using Rocky Linux 9, which comes with Asterisk 18.12.1, works nicely with SELinux enabled, and have no issues. The Asterisk docs say it will get fixes until 2025. After that, I’d imagine we’d get updates from RHEL to a newer LTS version (I’ve not actually asked the maintainers if this is actually planned). Even then, is it really something we should be concerned about right away?

It is very convenient to just use the one that is available in the repositories than have to compile it every time there is an update.

Upgraded to Asterisk 20.4.2. Ran this in a test environment all weekend and no issues with the testing. Put it into production this morning and about 10 hrs later started throwing the exact continuous errors as my original post; Here is the errors from /var/log/asterisk/full. It completely made asterisk unusable so I had to restart it… I will now need to figure out how to get a core dump and submit the issue.

Background Info: This is the EXACT configuration we have been running with in asterisk 16 for 4 years without issue. We also extensively use the ARI interface for call management… I will be rolling everthing back to Asterisk 16 since that works reliably…

[2024-11-11 16:21:26] ERROR[23862] stasis.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f06cc03ad10 (0)
[2024-11-11 16:21:26] ERROR[23862] : Got 17 backtrace records
# 0: /usr/sbin/asterisk(__ast_assert_failed+0x84) [0x5d4ffa]
# 1: /usr/sbin/asterisk() [0x4621df]
# 2: /usr/sbin/asterisk(__ao2_trylock+0x64) [0x462634]
# 3: /usr/sbin/asterisk(stasis_forward_all+0x1a2) [0x598d61]
# 4: /usr/lib64/asterisk/modules/res_stasis.so(+0xebbe) [0x7f0712a0dbbe]
# 5: /usr/lib64/asterisk/modules/res_stasis.so(+0x125b4) [0x7f0712a115b4]
# 6: /usr/lib64/asterisk/modules/res_stasis.so(+0x1854c) [0x7f0712a1754c]
# 7: /usr/lib64/asterisk/modules/res_stasis.so(+0x1874e) [0x7f0712a1774e]
# 8: /usr/lib64/asterisk/modules/res_stasis.so(+0x1535f) [0x7f0712a1435f]
# 9: /usr/lib64/asterisk/modules/res_stasis.so(+0x18c93) [0x7f0712a17c93]
#10: /usr/lib64/asterisk/modules/res_stasis.so(stasis_app_exec+0xc53) [0x7f0712a0a847]
#11: /usr/lib64/asterisk/modules/app_stasis.so(+0xb9f) [0x7f0708512b9f]
#12: /usr/sbin/asterisk(pbx_exec+0x11c) [0x5471cb]
#13: /usr/lib64/asterisk/modules/res_ari_channels.so(+0xb39d) [0x7f07018bf39d]
#14: /usr/sbin/asterisk() [0x5d21aa]
#15: /lib64/libpthread.so.0(+0x7ea5) [0x7f0782819ea5]
#16: /lib64/libc.so.6(clone+0x6d) [0x7f078099b8dd]

I have found a scenario where I can reproduce the issue very quickly.
I then submitted a bug report Bug #992.
This is a duplicate of bug report Bug #211 which was submitted back in July’24, and will be tracked by Bug #211.

This is a real issue in that I cannot upgrade Asterisk to get the latest security/bug fixes for our production system…

As part of triage I increased the priority of it in the queue at Sangoma, but have no time frame on it.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.