[SR-Users] Crash Kamailio 4.1 (qm_debug_frag(): BUG: qm_*: prev. fragm. tail overwritten)

Andrés Souto andres.souto at quobis.com
Tue Jun 10 14:26:38 CEST 2014 

I don't know the Kamailio internals but after that commit this crash does
not occur...

Yeah, I'm think the log is complete but it contains more than one
execution. I updated the file to a new log. Now it only contains one
executions from initialization until it crashes. The message is still not
present. Maybe it crashes at another point? is not being logged all the
execution?

The backtrace for the last log:

#0  0x00007f5189cb5475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f5189cb5475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f5189cb86f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x000000000057063f in qm_debug_frag (qm=qm at entry=0x7f5189882010,
f=f at entry=0x7f518995ba78) at mem/q_malloc.c:142
#3  0x00000000005716bd in qm_malloc (qm=0x7f5189882010, size=<optimized
out>, size at entry=1024,
    file=file at entry=0x5f997e "<core>: action.c", func=func at entry=0x5fac10
"do_action", line=line at entry=832) at mem/q_malloc.c:386
#4  0x0000000000423c61 in do_action (h=h at entry=0x7fff62578740,
a=a at entry=0x7fff62578820,
msg=0x7f5189958e08) at action.c:832
#5  0x00007f5186bc7347 in pv_set_ruri_user (msg=<optimized out>,
param=<optimized out>, op=<optimized out>, val=0x7fff62578990)
    at pv_core.c:2073
#6  0x000000000047a3ad in lval_pvar_assign (rv=0x7f51899491f0,
msg=0x7f5189958e08, h=<optimized out>, lv=<optimized out>) at lvalue.c:362
#7  lval_assign (h=h at entry=0x7fff6257b490, msg=msg at entry=0x7f5189958e08,
lv=0x7f5189948ae0, rve=0x7f51899491e8) at lvalue.c:410
#8  0x00000000004212f0 in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f5189948c48,
msg=msg at entry=0x7f5189958e08) at action.c:1478
#9  0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=0x7f518993dfc0, msg=msg at entry=0x7f5189958e08) at action.c:1599
#10 0x0000000000421d7b in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f518994aaf0,
msg=msg at entry=0x7f5189958e08) at action.c:1094
#11 0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=0x7f518994aaf0, msg=msg at entry=0x7f5189958e08) at action.c:1599
#12 0x0000000000421d7b in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f518994af30,
msg=msg at entry=0x7f5189958e08) at action.c:1094
#13 0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=0x7f518993ba90, msg=msg at entry=0x7f5189958e08) at action.c:1599
#14 0x0000000000421ef8 in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f51898fe0a0,
msg=msg at entry=0x7f5189958e08) at action.c:715
#15 0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=0x7f51898fc8e0, msg=msg at entry=0x7f5189958e08) at action.c:1599
#16 0x0000000000422428 in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f5189901bd0,
msg=msg at entry=0x7f5189958e08) at action.c:1365
#17 0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=0x7f51898fbfb8, msg=msg at entry=0x7f5189958e08) at action.c:1599
#18 0x0000000000421d7b in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f5189901df0,
msg=msg at entry=0x7f5189958e08) at action.c:1094
#19 0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=0x7f51898f92b8, msg=msg at entry=0x7f5189958e08) at action.c:1599
#20 0x0000000000421ef8 in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f51898e1e68,
msg=msg at entry=0x7f5189958e08) at action.c:715
#21 0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=0x7f51898e0c48, msg=msg at entry=0x7f5189958e08) at action.c:1599
#22 0x0000000000421d7b in do_action (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f51898e3918,
msg=msg at entry=0x7f5189958e08) at action.c:1094
#23 0x0000000000420940 in run_actions (h=h at entry=0x7fff6257b490,
a=a at entry=0x7f51898d9680,
msg=msg at entry=0x7f5189958e08) at action.c:1599
#24 0x0000000000429a50 in run_top_route (a=0x7f51898d9680,
msg=msg at entry=0x7f5189958e08,
c=c at entry=0x0) at action.c:1685
#25 0x00000000004bbb9e in receive_msg (buf=<optimized out>, len=<optimized
out>, rcv_info=<optimized out>) at receive.c:212
#26 0x000000000055fe21 in udp_rcv_loop () at udp_server.c:536




2014-06-10 13:08 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:

>  Hello,
>
>
> On 10/06/14 12:47, Andrés Souto wrote:
>
> Hello,
>
>  I'm not using tel2uri(). I tested it again and I can't reproduced it
> with the last commit in 4.1 branch. With version 4.1.3 it reproduces
> always. The problem seems to be present after more than one mysql query
> thus I thought it could be related with that commit. I try it
> at 642428cf8be1c7355f91b14276e888ec505cd69a and it also reproduces so it
> seems that it is solve by 94ebfb5d5973ed59de84ca0e0c87052b4c80f9de.
>
> That commit is related to a memleak when re-initializing/looking up the db
> connection at time.
>
>
>
>  The complete log for version 4.1.3 is here:
> https://www.dropbox.com/s/fn1l8lnfkn7o3bk/kamailio.log
>
> Is the log complete, because it doesn't have the message like:
>
> ... BUG: qm_*: prev. fragm. tail overwritten(c0c0c000, abcdefed)
>
>
> Cheers,
> Daniel
>
>
>
>
>
>
> 2014-06-09 21:03 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>
>>  Hello,
>>
>> the only patch that could fix such situation lately was in tel2uri()
>> function, are you using it? In the backtrace I didn't see a tel uri.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 09/06/14 20:57, Andrés Souto wrote:
>>
>> Hello again,
>>
>>  I have tested right now if it still reproduces with the current last
>> branch 4.1 git version and it seems to work. Tomorrow I'll do more testing
>> but probably it is already fixed
>> by 94ebfb5d5973ed59de84ca0e0c87052b4c80f9de.
>>
>>
>> 2014-06-09 20:46 GMT+02:00 Andrés Souto <andres.souto at quobis.com>:
>>
>>> Hello,
>>>
>>>  yes, I'm still have the core file. The issue reproduces always with
>>> this configuration.
>>>
>>>
>>> 2014-06-09 18:08 GMT+02:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>>
>>>
>>>  Hello,
>>>>
>>>> do you still have the core file for inspection? Can the issue be
>>>> reproduced?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 29/05/14 12:18, Andrés Souto wrote:
>>>>
>>>>   Hello,
>>>>
>>>>  Kamailio crashes with this message:
>>>>  May 29 12:03:45 kamfree-manager kamailio[8705]: : <core>
>>>> [mem/q_malloc.c:159]: qm_debug_frag(): BUG: qm_*: prev. fragm. tail
>>>> overwritten(c0c0c000, abcdefed)[0x7ff5a5031a98:0x7ff5a5031ac8]!
>>>> May 29 12:03:45 kamfree-manager kamailio[8697]: ALERT: <core>
>>>> [main.c:775]: handle_sigs(): child process 8705 exited by a signal 6
>>>> May 29 12:03:45 kamfree-manager kamailio[8697]: ALERT: <core>
>>>> [main.c:778]: handle_sigs(): core was generated
>>>>
>>>>  The problem is produced in this line of the script:
>>>> $rU = $dbr(ra=>[0,0]);
>>>>
>>>>  I'm using last commit in 4.1 branch
>>>> (ad5235229f59ba5d1f4216e144291e110fee0211) on Debian wheezy.
>>>>
>>>>  The backtrace:
>>>> #0  0x00007ff5a538b475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>>> #1  0x00007ff5a538e6f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
>>>> #2  0x0000000000546a00 in qm_debug_frag (qm=0x7ff5a4f58010,
>>>> f=0x7ff5a5031a98) at mem/q_malloc.c:161
>>>> #3  0x000000000054796d in qm_malloc (qm=0x7ff5a4f58010, size=1024,
>>>> file=0x5c9ec1 "<core>: action.c", func=0x5cb1d8 "do_action", line=832) at
>>>> mem/q_malloc.c:386
>>>> #4  0x000000000041affa in do_action (h=0x7fff810cd2b0,
>>>> a=0x7fff810cd390, msg=0x7ff5a502ed28) at action.c:832
>>>> #5  0x00007ff5a2295d88 in pv_set_ruri_user (msg=0x7ff5a502ed28,
>>>> param=0x7ff5a4fb3750, op=254, val=0x7fff810cd4e0) at pv_core.c:2073
>>>> #6  0x0000000000467bbf in lval_pvar_assign (h=0x7fff810d0200,
>>>> msg=0x7ff5a502ed28, lv=0x7ff5a501ea00, rv=0x7ff5a501f110) at lvalue.c:362
>>>> #7  0x00000000004680a5 in lval_assign (h=0x7fff810d0200,
>>>> msg=0x7ff5a502ed28, lv=0x7ff5a501ea00, rve=0x7ff5a501f108) at lvalue.c:410
>>>> #8  0x0000000000423fec in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a501eb68, msg=0x7ff5a502ed28) at action.c:1478
>>>> #9  0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a5013ee0, msg=0x7ff5a502ed28) at action.c:1599
>>>> #10 0x000000000041c18d in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a5020a10, msg=0x7ff5a502ed28) at action.c:1090
>>>> #11 0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a5020a10, msg=0x7ff5a502ed28) at action.c:1599
>>>> #12 0x000000000041c18d in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a5020e50, msg=0x7ff5a502ed28) at action.c:1090
>>>> #13 0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a50119b0, msg=0x7ff5a502ed28) at action.c:1599
>>>> #14 0x000000000041a2b7 in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a4fd3fc0, msg=0x7ff5a502ed28) at action.c:715
>>>> #15 0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a4fd2800, msg=0x7ff5a502ed28) at action.c:1599
>>>> #16 0x0000000000422c70 in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a4fd7af0, msg=0x7ff5a502ed28) at action.c:1235
>>>> #17 0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a4fd1ed8, msg=0x7ff5a502ed28) at action.c:1599
>>>> #18 0x000000000041c18d in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a4fd7d10, msg=0x7ff5a502ed28) at action.c:1090
>>>> #19 0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a4fcf1d8, msg=0x7ff5a502ed28) at action.c:1599
>>>> #20 0x000000000041a2b7 in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a4fb7d88, msg=0x7ff5a502ed28) at action.c:715
>>>> #21 0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a4fb6b68, msg=0x7ff5a502ed28) at action.c:1599
>>>> #22 0x000000000041c18d in do_action (h=0x7fff810d0200,
>>>> a=0x7ff5a4fb9838, msg=0x7ff5a502ed28) at action.c:1090
>>>> #23 0x0000000000424d70 in run_actions (h=0x7fff810d0200,
>>>> a=0x7ff5a4faf5a0, msg=0x7ff5a502ed28) at action.c:1599
>>>> #24 0x0000000000425524 in run_top_route (a=0x7ff5a4faf5a0,
>>>> msg=0x7ff5a502ed28, c=0x0) at action.c:1685
>>>> #25 0x00000000004a6fdb in receive_msg (
>>>>     buf=0x921920 "INVITE sip:2000 at vpbx2.ur SIP/2.0\r\nVia: SIP/2.0/UDP
>>>> 192.168.0.101;rport;branch=z9hG4bK14cFrXZ0N53jS\r\nMax-Forwards:
>>>> 67\r\nFrom: \"1000\" <sip:1000 at vpbx1.ur>;tag=FjmFN79ZrXH0e\r\nTo:
>>>> <sip:2000 at vpbx2.ur>\r\nCall-"..., len=1061, rcv_info=0x7fff810d04b0)
>>>> at receive.c:212
>>>> #26 0x000000000053c544 in udp_rcv_loop () at udp_server.c:536
>>>> ---Type <return> to continue, or q <return> to quit---
>>>> #27 0x000000000046ee54 in main_loop () at main.c:1617
>>>> #28 0x0000000000471df4 in main (argc=3, argv=0x7fff810d07e8) at
>>>> main.c:2533
>>>>
>>>>  Complete log: http://pastebin.com/YZirUkfe
>>>>
>>>>  Thanks.
>>>>
>>>>  Regards,
>>>>
>>>>  --
>>>>  *Andrés Souto*
>>>> VoIP Engineer @ Quobis <http://www.quobis.com/> | e:
>>>> andres.souto at quobis.com | t: +34902999465
>>>>
>>>>
>>>>  _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>>
>>>  --
>>>  *Andrés Souto*
>>> VoIP Engineer @ Quobis <http://www.quobis.com/> | e:
>>> andres.souto at quobis.com | t: +34902999465
>>>
>>
>>
>>
>>  --
>>  *Andrés Souto*
>> VoIP Engineer @ Quobis <http://www.quobis.com/> | e:
>> andres.souto at quobis.com | t: +34902999465
>>
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>
>
>  --
>  *Andrés Souto*
> VoIP Engineer @ Quobis <http://www.quobis.com/> | e:
> andres.souto at quobis.com | t: +34902999465
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>


-- 
*Andrés Souto*
VoIP Engineer @ Quobis <http://www.quobis.com/> | e: andres.souto at quobis.com |
t: +34902999465
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140610/72676219/attachment.html>

More information about the sr-users mailing list