Hangups during frame processing causing crash?

[InterLinked]

Things were going fine earlier today when all of a sudden Asterisk crashed and I saw this in the CLI:

[Apr 27 16:07:53]   == Using SIP RTP TOS bits 184
[Apr 27 16:07:53]   == Using SIP RTP CoS mark 5
[Apr 27 16:07:53]     -- Executing [1@from-centrex-1A1:1] Goto("SIP/ATAxLA2-000004b6", "from-centrex,1A1,1") in new stack
[Apr 27 16:07:53]     -- Goto (from-centrex,1A1,1)
[Apr 27 16:07:53]     -- Executing [1A1@from-centrex:1] Set("SIP/ATAxLA2-000004b6", "CDR_PROP(disable)=1") in new stack
[Apr 27 16:07:53]     -- Executing [1A1@from-centrex:2] Answer("SIP/ATAxLA2-000004b6", "") in new stack
[Apr 27 16:07:53]     -- Executing [1A1@from-centrex:3] Set("SIP/ATAxLA2-000004b6", "__fullpeername=SIP/ATAxLA2") in new stack
[Apr 27 16:07:53]     -- Executing [1A1@from-centrex:4] ExecIf("SIP/ATAxLA2-000004b6", "1?Hangup(101)") in new stack
[Apr 27 16:07:53]   == Spawn extension (from-centrex, 1A1, 4) exited non-zero on 'SIP/ATAxLA2-000004b6'
[2021-04-27 16:07:54] ERROR[17098][C-00000f58]: channel.c:1021 __ast_queue_frame: FRACK!, Failed assertion user_data is NULL (0)
[2021-04-27 16:07:54] ERROR[17098][C-00000f58]:   Got 9 backtrace records
# 0: /usr/sbin/asterisk(__ao2_lock+0x207) [0x55c81572d127]
# 1: /usr/sbin/asterisk(+0x9ca71) [0x55c815760a71]
# 2: /usr/lib/asterisk/modules/chan_sip.so(+0x4c9be) [0x7f3d178db9be]
# 3: /usr/lib/asterisk/modules/chan_sip.so(+0x915c5) [0x7f3d179205c5]
# 4: /usr/lib/asterisk/modules/chan_sip.so(+0x94003) [0x7f3d17923003]
# 5: /usr/lib/asterisk/modules/chan_sip.so(+0x949b1) [0x7f3d179239b1]
# 6: /usr/sbin/asterisk(+0x1b3e7c) [0x55c815877e7c]
# 7: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f3d37773fa3]
# 8: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f3d3734a4cf]

channel.c:1021 is ast_lock_channel(), and so it looks like Asterisk crashed when processing a frame.

I can’t recall Asterisk ever dumping a backtrace for me without me telling it to (not currently running in debug mode). Unfortunately, I’m not sure how this might have happened so I don’t think I can replicate this, but does anyone know what this might be related to? Wondering if this is this something I should submit as a bug in JIRA, or if this is this likely something specific to my switch.

The only thing that seems pertinent is what immediately preceded the crash - hanging up on a device with a hangup cause code of 101. That hasn’t caused issues in the past, but it seems like there should have been data for that frame and perhaps the channel was removed it wasn’t there anymore.

[jcolp]

It occurred due to code in chan_sip, that’s about the extent of what can be said. Without further details like an actual backtrace noone would be able to determine, and since it’s chan_sip it is community supported.

[InterLinked]

Is it even possible to get that now that I’ve restarted Asterisk? I don’t see a core dump file in any of the usual Asterisk system directories to run coredumper on. Since I didn’t try to crash it myself, where would this file likely be located? This doesn’t work:

sudo /var/lib/asterisk/scripts/ast_coredumper --latest
No coredumps found

[jcolp]

If the script didn’t find it then it may not be present. Core dumps are a system thing, where they are located is dependent on the system itself. Mine show up in /tmp, but they’ve appeared elsewhere on other systems/distros.