I think the memory is corrupted here and it was corrupted before these
calls were made.
There was a similar issue in older versions when a module was run on
top of the dialog module.
That was fixed by introducing a new callback in the tm module.
Here, it may be that the memory was corrupted by some other module and
the dialog caught it.
Regards,
Ovidiu Sas
On Thu, Oct 21, 2010 at 9:50 AM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
Hmm, let me try to break it down:
On 20.10.2010 19:26, Alex Balashov wrote:
On 10/20/2010 12:54 PM, Andrei Pelinescu-Onciul
wrote:
> 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
^^^^^^^^^^^^^^^^^^^^^^
That corresponds to a call to shm_free() regarding the callee's CSeq number:
if (dlg->cseq[DLG_CALLEE_LEG].s)
shm_free(dlg->cseq[DLG_CALLEE_LEG].s);
As you can see, it's checked.
#3 0x00002b343dd6a2ea in destroy_dlg
(dlg=0x2b343fe1d6f8) at
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).
Found it:
Oct 19 18:47:35 kamgw01 /usr/local/sbin/kamailio[21845]: : <core>
[mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first
free: dialog: dlg_hash.c: dlg_set_leg_info(301) - aborting
That corresponds to another freeing operation, again making sure
beforehand that memory is still allocated:
if (dlg->cseq[leg].s) shm_free(dlg->cseq[leg].s);
Oct 19 18:47:36 kamgw01
/usr/local/sbin/kamailio[21830]: : <core>
[mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first
free: tm: h_table.c: free_cell(209) - aborting
That corresponds to freeing a series of To-tags:
tt=dead_cell->fwded_totags;
while(tt) {
...
shm_free_unsafe(tt);
...
}
Although it's unsafe it doesn't look related to a dialog's CSeq number
or even a dialog structure.
In short: I don't quite get it. :)
--Timo
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev