On Oct 19, 2010 at 19:02, Alex Balashov <abalashov(a)evaristesys.com> wrote:
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?
It looks like somebody tried to free() twice the same pointer
(if you look in the log you will see a BUG message about it, including
the file and line where it was free()'d first).
This is with CANCEL_REASON_SUPPORT #undef'd in tm_reply.h, btw.
Andrei