This is the backtrace of 2 core-dumps i got just recently (both with the same timestamp). Nothing obvious that hits my eyes (at least no NULL pointer). Maybe you can see more in it.
Backtrace #1: =========== [New LWP 99122] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067b2a60, p_msg=0x7fca0d8fd020, branch=0, msg_status=401, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bKe4bf.c46a843afa3ff97f5b20df53926515a2.0;i=62\r\nVia: SIP/2.0/TCP 195.225.36.194:1797;rport=40047;"..., len=736, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Backtrace #2: =========== [New LWP 99120] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067da3c0, p_msg=0x7fca0d8fd020, branch=0, msg_status=200, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bK3494.0e37cca5019fe3c95285a3464d0eaa5e.0;i=b3\r\nVia: SIP/2.0/TCP 192.168.0.102:53360;rport=53360;received=9"..., len=638, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Think you can try make you systemd unit files change like this https://github.com/kamailio/kamailio/pull/1197/files
I expect you daemon restart will be fixed https://github.com/kamailio/kamailio/issues/1085
Sergey
вт, 9 окт. 2018 г. в 11:58, Floimair Florian f.floimair@commend.com:
This is the backtrace of 2 core-dumps i got just recently (both with the same timestamp). Nothing obvious that hits my eyes (at least no NULL pointer). Maybe you can see more in it.
Backtrace #1:
[New LWP 99122] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067b2a60, p_msg=0x7fca0d8fd020, branch=0, msg_status=401, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bKe4bf.c46a843afa3ff97f5b20df53926515a2.0;i=62\r\nVia: SIP/2.0/TCP 195.225.36.194:1797;rport=40047;"..., len=736, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Backtrace #2:
[New LWP 99120] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067da3c0, p_msg=0x7fca0d8fd020, branch=0, msg_status=200, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bK3494.0e37cca5019fe3c95285a3464d0eaa5e.0;i=b3\r\nVia: SIP/2.0/TCP 192.168.0.102:53360;rport=53360;received=9"..., len=638, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Yeah, that’s exactly what I have already done. But thanks for the info.
Von: sr-users sr-users-bounces@lists.kamailio.org im Auftrag von Sergey Safarov s.safarov@gmail.com Antworten an: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Datum: Dienstag, 9. Oktober 2018 um 11:53 An: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Betreff: Re: [SR-Users] Kamailio 5.1.6 Debian Package -> SEGFAULT
Think you can try make you systemd unit files change like this https://github.com/kamailio/kamailio/pull/1197/files
I expect you daemon restart will be fixed https://github.com/kamailio/kamailio/issues/1085
Sergey
вт, 9 окт. 2018 г. в 11:58, Floimair Florian <f.floimair@commend.commailto:f.floimair@commend.com>: This is the backtrace of 2 core-dumps i got just recently (both with the same timestamp). Nothing obvious that hits my eyes (at least no NULL pointer). Maybe you can see more in it.
Backtrace #1: =========== [New LWP 99122] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067b2a60, p_msg=0x7fca0d8fd020, branch=0, msg_status=401, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bKe4bf.c46a843afa3ff97f5b20df53926515a2.0;i=62\r\nVia: SIP/2.0/TCP 195.225.36.194:1797;rport=40047;"..., len=736, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Backtrace #2: =========== [New LWP 99120] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067da3c0, p_msg=0x7fca0d8fd020, branch=0, msg_status=200, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bK3494.0e37cca5019fe3c95285a3464d0eaa5e.0;i=b3\r\nVia: SIP/2.0/TCP 192.168.0.102:53360;rport=53360;received=9"..., len=638, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
does it happen that you have the pcap with the sip trace for this call? If yes, can you send it to me (can be sent directly if you have some sensitive data there)?
Also, please send me the output from gdb with the following commands:
list
info locals
p *Trans
Cheers, Daniel
On 09.10.18 10:58, Floimair Florian wrote:
This is the backtrace of 2 core-dumps i got just recently (both with the same timestamp). Nothing obvious that hits my eyes (at least no NULL pointer). Maybe you can see more in it.
Backtrace #1:
[New LWP 99122] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067b2a60, new_code=401, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067b2a60, p_msg=0x7fca0d8fd020, branch=0, msg_status=401, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 401 Unauthorized\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bKe4bf.c46a843afa3ff97f5b20df53926515a2.0;i=62\r\nVia: SIP/2.0/TCP 195.225.36.194:1797;rport=40047;"..., len=736, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Backtrace #2:
[New LWP 99120] [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/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 1282 t_reply.c: No such file or directory. (gdb) bt #0 0x00007fca0d45e996 in t_should_relay_response (Trans=0x7fca067da3c0, new_code=200, branch=0, should_store=0x7ffff47edd44, should_relay=0x7ffff47edd40, cancel_data=0x7ffff47edf30, reply=0x7fca0d8fd020) at t_reply.c:1282 #1 0x00007fca0d46317f in relay_reply (t=0x7fca067da3c0, p_msg=0x7fca0d8fd020, branch=0, msg_status=200, cancel_data=0x7ffff47edf30, do_put_on_wait=1) at t_reply.c:1786 #2 0x00007fca0d469154 in reply_received (p_msg=0x7fca0d8fd020) at t_reply.c:2537 #3 0x000055e77686fbe3 in do_forward_reply (msg=0x7fca0d8fd020, mode=0) at core/forward.c:747 #4 0x000055e776871a00 in forward_reply (msg=0x7fca0d8fd020) at core/forward.c:852 #5 0x000055e7768bd4e7 in receive_msg ( buf=0x55e776da0520 <buf> "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.17.217.10;rport=5060;received=172.17.217.10;branch=z9hG4bK3494.0e37cca5019fe3c95285a3464d0eaa5e.0;i=b3\r\nVia: SIP/2.0/TCP 192.168.0.102:53360;rport=53360;received=9"..., len=638, rcv_info=0x7ffff47ee4e0) at core/receive.c:364 #6 0x000055e7767ce4fe in udp_rcv_loop () at core/udp_server.c:554 #7 0x000055e77673a15d in main_loop () at main.c:1619 #8 0x000055e7767421fe in main (argc=13, argv=0x7ffff47eeb98) at main.c:2638
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Tue, Oct 09, 2018 at 01:09:46PM +0200, Daniel-Constantin Mierla wrote:
Hello,
does it happen that you have the pcap with the sip trace for this call? If yes, can you send it to me (can be sent directly if you have some sensitive data there)?
Is there any progress on debugging this? I'm also seeing crashes a few times a day on 2 specific machines (running the same config) since the update (while others are just running fine).
I'll see if I can provide the necessary information if needed.
Hello,
I pushed a commit based on the back traces sent on this thread: 39b89a18a8c357151a173ab02dc95dff1f02715d
Not sure if this commit was back ported to 5.1, though.
However, there was no follow up, Florian said he has to monitor after doing some fixes on the system and see how it goes. Since then I haven't see another update, so if you can get gdb backtrace, we can see if it is related or not.
Cheers, Daniel
On Wed, Jan 2, 2019 at 2:24 PM Daniel Tryba d.tryba@pocos.nl wrote:
On Tue, Oct 09, 2018 at 01:09:46PM +0200, Daniel-Constantin Mierla wrote:
Hello,
does it happen that you have the pcap with the sip trace for this call? If yes, can you send it to me (can be sent directly if you have some sensitive data there)?
Is there any progress on debugging this? I'm also seeing crashes a few times a day on 2 specific machines (running the same config) since the update (while others are just running fine).
I'll see if I can provide the necessary information if needed.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Wed, Jan 02, 2019 at 03:25:55PM +0100, Daniel-Constantin Mierla wrote:
However, there was no follow up, Florian said he has to monitor after doing some fixes on the system and see how it goes. Since then I haven't see another update, so if you can get gdb backtrace, we can see if it is related or not.
My crashes don't appear to be related, see https://github.com/kamailio/kamailio/issues/1784 Mine are triggered by topos/redis, even though I have topos disabled with an even route.
This turned out to be unrelated to Kamailio itself in our case. The problem was that the systemd-journald of the systemd version shipped with Debian stretch was sometimes eating up our CPU time on a single-core VM. After upgrading to systemd from stretch-backports we no longer had any issues.
With best regards
Florian Floimair Innovation - Software-Development
COMMEND INTERNATIONAL GMBH A-5020 Salzburg, Saalachstraße 51 http://www.commend.com http://www.commend.com/
Security and Communication by Commend
FN 178618z | LG Salzburg
Am 03.01.19, 13:31 schrieb "sr-users im Auftrag von Daniel Tryba" <sr-users-bounces@lists.kamailio.org im Auftrag von d.tryba@pocos.nl>:
On Wed, Jan 02, 2019 at 03:25:55PM +0100, Daniel-Constantin Mierla wrote: > However, there was no follow up, Florian said he has to monitor after doing > some fixes on the system and see how it goes. Since then I haven't see > another update, so if you can get gdb backtrace, we can see if it is > related or not.
My crashes don't appear to be related, see https://github.com/kamailio/kamailio/issues/1784 Mine are triggered by topos/redis, even though I have topos disabled with an even route.
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Mon, Jan 07, 2019 at 04:21:35PM +0000, Floimair Florian wrote:
This turned out to be unrelated to Kamailio itself in our case. The problem was that the systemd-journald of the systemd version shipped with Debian stretch was sometimes eating up our CPU time on a single-core VM. After upgrading to systemd from stretch-backports we no longer had any issues.
Thanks for the feedback. Haven't seen the problem you describe with systemd yet. Will investigate since we are a Debian shop.
On 03.01.19 13:30, Daniel Tryba wrote:
On Wed, Jan 02, 2019 at 03:25:55PM +0100, Daniel-Constantin Mierla wrote:
However, there was no follow up, Florian said he has to monitor after doing some fixes on the system and see how it goes. Since then I haven't see another update, so if you can get gdb backtrace, we can see if it is related or not.
My crashes don't appear to be related, see https://github.com/kamailio/kamailio/issues/1784 Mine are triggered by topos/redis, even though I have topos disabled with an even route.
I requested some extra info from the corefile on the back tracker.
To understand properly the use case: you have topos and topos_redis, but you use the event_route to "drop" doing topology stripping?
Cheers, Daniel
On Tue, Jan 08, 2019 at 11:40:56AM +0100, Daniel-Constantin Mierla wrote:
My crashes don't appear to be related, see https://github.com/kamailio/kamailio/issues/1784 Mine are triggered by topos/redis, even though I have topos disabled with an even route.
I requested some extra info from the corefile on the back tracker.
Updated the info.
To understand properly the use case: you have topos and topos_redis, but you use the event_route to "drop" doing topology stripping?
Yes. I initially had it enabled but later disabled it for testing with a drop in the event_route and never removed it. In 5.1.3 there was no problem, the moment I updated to 5.1.6 the segfaults began and continued til I removed topos/redis from the config.
On 08.01.19 11:54, Daniel Tryba wrote:
On Tue, Jan 08, 2019 at 11:40:56AM +0100, Daniel-Constantin Mierla wrote:
My crashes don't appear to be related, see https://github.com/kamailio/kamailio/issues/1784 Mine are triggered by topos/redis, even though I have topos disabled with an even route.
I requested some extra info from the corefile on the back tracker.
Updated the info.
OK, will dig in further.
To understand properly the use case: you have topos and topos_redis, but you use the event_route to "drop" doing topology stripping?
Yes. I initially had it enabled but later disabled it for testing with a drop in the event_route and never removed it. In 5.1.3 there was no problem, the moment I updated to 5.1.6 the segfaults began and continued til I removed topos/redis from the config.
There was some work done for supporting PRACK, I do not recall exactly when it was done, but could be the cause...
Cheers, Daniel
On Tue, Jan 08, 2019 at 12:08:23PM +0100, Daniel-Constantin Mierla wrote:
Yes. I initially had it enabled but later disabled it for testing with a drop in the event_route and never removed it. In 5.1.3 there was no problem, the moment I updated to 5.1.6 the segfaults began and continued til I removed topos/redis from the config.
There was some work done for supporting PRACK, I do not recall exactly when it was done, but could be the cause...
The good news is that even though kamailio crashed a few time per day, the impact was minimal. I haven't seen any calls fail, kamailio was back up and running within 3 or 4 seconds, well within retry timeouts.
On 08.01.19 12:26, Daniel Tryba wrote:
On Tue, Jan 08, 2019 at 12:08:23PM +0100, Daniel-Constantin Mierla wrote:
Yes. I initially had it enabled but later disabled it for testing with a drop in the event_route and never removed it. In 5.1.3 there was no problem, the moment I updated to 5.1.6 the segfaults began and continued til I removed topos/redis from the config.
There was some work done for supporting PRACK, I do not recall exactly when it was done, but could be the cause...
The good news is that even though kamailio crashed a few time per day, the impact was minimal. I haven't seen any calls fail, kamailio was back up and running within 3 or 4 seconds, well within retry timeouts.
I pushed a patch for it, will follow up with more details via the issue tracker.
Cheers, Daniel
-
Daniel Tryba -
Daniel-Constantin Mierla -
Floimair Florian -
Sergey Safarov