[sr-dev] kamailio core dumps once every few days

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)