kamailio core dumps once every few days - sr-users

27 Nov 2016

Gents,

On a not really loaded kamailio (less than 50 users at the moment),
I'm getting a core dump every few days. I've tried multiple verisons
of Kamailio, 4.4.x , 4.3.x and also on 5.0.0-dev7 .

I can't reproduce it adhoc, but every few days it happens...

Is that something someone wants to jump in?

grtz,
davy

Version: version: kamailio 5.0.0-dev7 (x86_64/linux) 7360b0

[New LWP 29728]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio.pid -f /usr/local/etc/kamailio//k'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x00007f92c5a0be98 in __dialog_sendpublish (dlg=0x7f92c0e3a6c0,
type=64, _params=0x7f92c0423500 <params>) at pua_dialoginfo.c:264

264 uri = dlginfo->to_uri;

(gdb) backtrace

#0  0x00007f92c5a0be98 in __dialog_sendpublish (dlg=0x7f92c0e3a6c0,
type=64, _params=0x7f92c0423500 <params>) at pua_dialoginfo.c:264

#1  0x00007f92c01e2563 in run_dlg_callbacks (type=64,
dlg=0x7f92c0e3a6c0, req=0x7f92cc6d5db8, rpl=0x0, dir=1, dlg_data=0x0)
at dlg_cb.c:256

#2  0x00007f92c01a92b1 in dlg_terminated (req=0x7f92cc6d5db8,
dlg=0x7f92c0e3a6c0, dir=1) at dlg_handlers.c:366

#3  0x00007f92c01b610f in dlg_onroute (req=0x7f92cc6d5db8,
route_params=0x7ffc7de27ba0, param=0x0) at dlg_handlers.c:1409

#4  0x00007f92c9292171 in run_rr_callbacks (req=0x7f92cc6d5db8,
rr_param=0x7ffc7de27c20) at rr_cb.c:96

#5  0x00007f92c9287ac2 in after_loose (_m=0x7f92cc6d5db8, preloaded=0)
at loose.c:928

#6  0x00007f92c9288168 in loose_route (_m=0x7f92cc6d5db8) at loose.c:962

#7  0x00007f92c928b7ee in w_loose_route (msg=0x7f92cc6d5db8, p1=0x0,
p2=0x0) at rr_mod.c:266

#8  0x000000000041f5d9 in do_action (h=0x7ffc7de285b0,
a=0x7f92cc5f7a70, msg=0x7f92cc6d5db8) at action.c:1054

#9  0x000000000042bcde in run_actions (h=0x7ffc7de285b0,
a=0x7f92cc5f7a70, msg=0x7f92cc6d5db8) at action.c:1552

#10 0x000000000042c383 in run_actions_safe (h=0x7ffc7de29c60,
a=0x7f92cc5f7a70, msg=0x7f92cc6d5db8) at action.c:1620

#11 0x000000000061fe86 in rval_get_int (h=0x7ffc7de29c60,
msg=0x7f92cc6d5db8, i=0x7ffc7de28cc0, rv=0x7f92cc5f7bc8, cache=0x0) at
rvalue.c:912

#12 0x00000000006243c3 in rval_expr_eval_int (h=0x7ffc7de29c60,
msg=0x7f92cc6d5db8, res=0x7ffc7de28cc0, rve=0x7f92cc5f7bc0) at
rvalue.c:1910

#13 0x000000000041f0d1 in do_action (h=0x7ffc7de29c60,
a=0x7f92cc600430, msg=0x7f92cc6d5db8) at action.c:1030

#14 0x000000000042bcde in run_actions (h=0x7ffc7de29c60,
a=0x7f92cc600430, msg=0x7f92cc6d5db8) at action.c:1552

#15 0x000000000041f548 in do_action (h=0x7ffc7de29c60,
a=0x7f92cc6006d0, msg=0x7f92cc6d5db8) at action.c:1045

#16 0x000000000042bcde in run_actions (h=0x7ffc7de29c60,
a=0x7f92cc6006d0, msg=0x7f92cc6d5db8) at action.c:1552

#17 0x000000000041c0fb in do_action (h=0x7ffc7de29c60,
a=0x7f92cc545730, msg=0x7f92cc6d5db8) at action.c:678

#18 0x000000000042bcde in run_actions (h=0x7ffc7de29c60,
a=0x7f92cc537760, msg=0x7f92cc6d5db8) at action.c:1552

#19 0x000000000042c44b in run_top_route (a=0x7f92cc537760,
msg=0x7f92cc6d5db8, c=0x0) at action.c:1641

#20 0x00000000005726a2 in receive_msg (

    buf=0xa1c200 <buf> "BYE sip:echo@123.48.11.215:5070;transport=udp
SIP/2.0\r\nVia: SIP/2.0/UDP
0.0.0.0:5060;rport;branch=z9hG4bKPj26b505ba-7ede-4198-a917-bde966b6d8b6\r\nMax-Forwards:
69\r\nFrom: sip:192.168.60.1;tag=9a10d8ab-"..., len=462,
rcv_info=0x7ffc7de29fb0) at receive.c:264

#21 0x000000000047bcdc in udp_rcv_loop () at udp_server.c:507

#22 0x0000000000509de1 in main_loop () at main.c:1618

#23 0x00000000005112de in main (argc=5, argv=0x7ffc7de2a478) at main.c:2639

(gdb)