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@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@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@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@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@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 | e: andres.souto@quobis.com | t: +34902999465
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--

Andrés Souto

VoIP Engineer @ Quobis | e: andres.souto@quobis.com | t: +34902999465
--

Andrés Souto

VoIP Engineer @ Quobis | e: andres.souto@quobis.com | t: +34902999465
-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
--

Andrés Souto

VoIP Engineer @ Quobis | e: andres.souto@quobis.com | t: +34902999465
-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Andrés Souto

VoIP Engineer @ Quobis | e: andres.souto@quobis.com | t: +34902999465