We had another one of these today, under high call volume:
(gdb) where #0 0x0000003a60430265 in raise () from /lib64/libc.so.6 #1 0x0000003a60431d10 in abort () from /lib64/libc.so.6 #2 0x0000000000530a91 in qm_free (qm=0x2b343e1aa000, p=0x2b343eddf6e8, file=0x2b343dd860c3 "dialog: dlg_hash.c", func=0x2b343dd86b42 "destroy_dlg", line=176) at mem/q_malloc.c:447 #3 0x00002b343dd6a2ea in destroy_dlg (dlg=0x2b343fe1d6f8) at dlg_hash.c:176 #4 0x00002b343dd6d33a in unref_dlg (dlg=0x2b343fe1d6f8, cnt=1) at dlg_hash.c:591 #5 0x00002b343dd73a04 in profile_cleanup (msg=<value optimized out>, flags=<value optimized out>, param=0x6) at dlg_profile.c:317 #6 0x00000000004be9a1 in exec_post_script_cb (msg=0xa06e80, type=<value optimized out>) at script_cb.c:195 #7 0x00000000004989f0 in receive_msg ( buf=0x8b6300 "BYE sip:15746317356@yyy.yyy.yyy.yyy:5060 SIP/2.0\r\nRecord-Route: sip:yyy.yyy.yyy.yyy;lr;ftag=gK0ebaf6d4\r\nRecord-Route: sip:67.231.8.89;lr;ftag=gK0ebaf6d4\r\nVia: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bKd757."..., len=<value optimized out>, rcv_info=0x7fff4a043230) at receive.c:221 #8 0x000000000052576a in udp_rcv_loop () at udp_server.c:532 #9 0x0000000000468dcd in main_loop () at main.c:1554 #10 0x000000000046be9f in main (argc=<value optimized out>, argv=0x7fff4a043508) at main.c:2398
Is this a regression, or memory corruption from something else?
This is with CANCEL_REASON_SUPPORT #undef'd in tm_reply.h, btw.