10 Jun
2014
10 Jun
'14
3:26 p.m.
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@entry=0x7f5189882010,
f=f@entry=0x7f518995ba78) at mem/q_malloc.c:142
#3 0x00000000005716bd in qm_malloc (qm=0x7f5189882010, size=<optimized
out>, size@entry=1024,
file=file@entry=0x5f997e "<core>: action.c", func=func@entry=0x5fac10
"do_action", line=line@entry=832) at mem/q_malloc.c:386
#4 0x0000000000423c61 in do_action (h=h@entry=0x7fff62578740,
a=a@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@entry=0x7fff6257b490, msg=msg@entry=0x7f5189958e08,
lv=0x7f5189948ae0, rve=0x7f51899491e8) at lvalue.c:410
#8 0x00000000004212f0 in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f5189948c48,
msg=msg@entry=0x7f5189958e08) at action.c:1478
#9 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=0x7f518993dfc0, msg=msg@entry=0x7f5189958e08) at action.c:1599
#10 0x0000000000421d7b in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f518994aaf0,
msg=msg@entry=0x7f5189958e08) at action.c:1094
#11 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=0x7f518994aaf0, msg=msg@entry=0x7f5189958e08) at action.c:1599
#12 0x0000000000421d7b in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f518994af30,
msg=msg@entry=0x7f5189958e08) at action.c:1094
#13 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=0x7f518993ba90, msg=msg@entry=0x7f5189958e08) at action.c:1599
#14 0x0000000000421ef8 in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f51898fe0a0,
msg=msg@entry=0x7f5189958e08) at action.c:715
#15 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=0x7f51898fc8e0, msg=msg@entry=0x7f5189958e08) at action.c:1599
#16 0x0000000000422428 in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f5189901bd0,
msg=msg@entry=0x7f5189958e08) at action.c:1365
#17 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=0x7f51898fbfb8, msg=msg@entry=0x7f5189958e08) at action.c:1599
#18 0x0000000000421d7b in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f5189901df0,
msg=msg@entry=0x7f5189958e08) at action.c:1094
#19 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=0x7f51898f92b8, msg=msg@entry=0x7f5189958e08) at action.c:1599
#20 0x0000000000421ef8 in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f51898e1e68,
msg=msg@entry=0x7f5189958e08) at action.c:715
#21 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=0x7f51898e0c48, msg=msg@entry=0x7f5189958e08) at action.c:1599
#22 0x0000000000421d7b in do_action (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f51898e3918,
msg=msg@entry=0x7f5189958e08) at action.c:1094
#23 0x0000000000420940 in run_actions (h=h@entry=0x7fff6257b490,
a=a@entry=0x7f51898d9680,
msg=msg@entry=0x7f5189958e08) at action.c:1599
#24 0x0000000000429a50 in run_top_route (a=0x7f51898d9680,
msg=msg@entry=0x7f5189958e08,
c=c@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(a)gmail.com>om>:
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(a)gmail.com>om>:
--
*Andrés Souto*
VoIP Engineer @ Quobis <http://www.quobis.com/> | e: andres.souto(a)quobis.com |
t: +34902999465
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(a)quobis.com>om>:
--
*Andrés Souto*
VoIP Engineer @ Quobis <http://www.quobis.com/> | e:
andres.souto(a)quobis.com | t: +34902999465
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
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(a)gmail.com>om>:
Hello,
--
*Andrés Souto*
VoIP Engineer @ Quobis <http://www.quobis.com/> | e:
andres.souto(a)quobis.com | t: +34902999465
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
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@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@vpbx1.ur>;tag=FjmFN79ZrXH0e\r\nTo:
<sip:2000@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(a)quobis.com | t: +34902999465
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@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(a)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(a)quobis.com | t: +34902999465