I have a busy Asterisk system at a doctors clinic (a very large one) which is using Asterisk queuing for incoming calls. Its currently running Asterisk 13.18.5. It has been running fine for well over a year now.
I recently added an IVR in front of the queue and was forced to revert the change due to regular segfaults:
Mar 26 08:35:22 3037-QGPSC-CM1 user.info kernel: asterisk: segfault at 10 ip 00002ad14c5a319c sp 00002ad15229dcd0 error 4 in app_queue.so[2ad14c58a000+36000]
Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on signal 11.
Mar 26 08:35:23 3037-QGPSC-CM1 user.info safe_asterisk: Automatically restarting Asterisk.
Now I was previously experiencing identical app_queue segfaults on this system (log messages only) when using a different dialplan setup of cascading queues. At the time I suspected that I was having issues with ASTERISK-27006 and after reverting the Asterisk version to 13.14.1 the problem went away. Since then I have changed the dialplan back to a standard single queue setup and have upgraded the Asterisk version to 13.18.5 and I suspect that I am experiencing the same bug.
I build generic dialplan modules which create a Local channel between them during the call flow so the caller would be connected from the IVR to the queue via a Local Channel. I suspect that is the reason why this bug is coming into play again.
So my questions are:
- Does this look like I am still experiencing ASTERISK-27006?
- If so, as its still not resolved, do I need to revert back to 13.14.1?
- Would it be worth rebuilding the dialplan so there is no Local Channel between the IVR and queue?
- Anything else I could try?
Unfortunately getting a backtrace is going to be problematic as they are extremely busy at the moment with COVID-19 calls and I dont really want to crash the system again.
Thanks so much all.