Backtrace and Errors with Statis/Pool Task Processor

[clay.dirkschneider]

Over the weekend, I noticed that my asterisk server was getting a whole bunch of these backtrace records about every 15minutes:

[Apr 11 00:18:49] ERROR[12849] chan_sip.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f9700075450 (0)
[Apr 11 00:18:49] ERROR[12849] : Got 10 backtrace records

0: /usr/sbin/asterisk(__ao2_ref+0x5e3) [0x562358380fd3]

1: /usr/lib/asterisk/modules/chan_sip.so(+0x71820) [0x7f971eacc820]

2: /usr/sbin/asterisk(+0x183b00) [0x56235849ab00]

3: /usr/sbin/asterisk(ast_taskprocessor_execute+0x176) [0x5623584bbc36]

4: /usr/sbin/asterisk(+0x1ab160) [0x5623584c2160]

5: /usr/sbin/asterisk(ast_taskprocessor_execute+0xc7) [0x5623584bbb87]

6: /usr/sbin/asterisk(+0x1abb44) [0x5623584c2b44]

7: /usr/sbin/asterisk(+0x1b353c) [0x5623584ca53c]

8: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f9721e2cfa3]

9: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f9721a034cf]

Preceding it were these warnings:

[Apr 11 00:16:26] WARNING[23815] taskprocessor.c: The ‘stasis/pool’ task processor queue reached 500 scheduled tasks again.
[Apr 11 00:16:26] WARNING[23815] taskprocessor.c: The ‘stasis/pool-control’ task processor queue reached 500 scheduled tasks again.

I know that during this late night that there is nothing going on as this is a development environment and nothing should be happening. I restarted Asterisk and now the errors have disappeared so I am unable to troubleshoot further. I am hoping to see if anyone might have an idea of what is going on.

Background: This asterisk server is running 18.2.2 on top of Debian 10. It is running realtime database for sippeers, voicemail users, and voicemail messages. I had recently enabled voicemail on the server and that is working as intended. We are using ARI to control calls since we were unable to do what we wanted with the dialplan. If you need more information, let me know.

[kharwell]

Unfortunately, it’s hard to say given the information at hand. You can follow the guide here (getting a backtrace) and get a proper backtrace to see if it gives more data about the problem. However, there does appear to already be several similar issues reported against chan_sip:

https://issues.asterisk.org/jira/browse/ASTERISK-29069
https://issues.asterisk.org/jira/browse/ASTERISK-28627
https://issues.asterisk.org/jira/browse/ASTERISK-28278

If it’s possible you might move things over to chan_pjsip.

Lastly those “queue reached” warnings occur when there is a backup in the system. Or the system resources are being taxed. More information here. Maybe a bunch of endpoints are re-registering at the same time? System getting attacked? Perhaps the database is blocking (some weekend “cleanup” task), and then causing other stuff to backup.