In Kamailio 3.1.0, I get an occasional crash that appears to be due to topoh. Here is the backtrace from the core file, though the binary was not compiled with debug symbols and so some things have definitely been optimised out:
Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 1024 -u root -g r'. Program terminated with signal 11, Segmentation fault. [New process 11535] #0 th_del_via_cookie (msg=0x7fffcca2bbe0, via=0x0) at th_msg.c:951 951 for(p=via->param_lst; p; p=p->next) (gdb) where #0 th_del_via_cookie (msg=0x7fffcca2bbe0, via=0x0) at th_msg.c:951 #1 0x00007f528da90eb4 in th_del_cookie (msg=0x7fffcca2bbe0) at th_msg.c:972 #2 0x00007f528da97748 in th_msg_sent (data=<value optimized out>) at topoh_mod.c:288 #3 0x00007f528f98d1d7 in send_pr_buffer (rb=0x7f5249acc0d8, buf=0x7f528fbe50a0, len=3) at ../../forward.h:133 #4 0x00007f528f9bdffd in t_retransmit_reply (t=0x7f5249acc018) at t_reply.c:1411 #5 0x00007f528f998c17 in retr_buf_handler (ticks=291591695, tl=0x7f5249acc0f8, p=<value optimized out>) at timer.c:367 #6 0x0000000000513e7f in timer_main () at timer.c:894 #7 0x0000000000464c7b in main_loop () at main.c:1618 #8 0x00000000004674d3 in main (argc=<value optimized out>, argv=0x7fffcca2c638) at main.c:2398
This is not a bug I can easily reproduce, and is probably due to an extremely unusual situation. This particular peer that is being interoperated with has a history of eccentric behaviour that makes no sense. Nevertheless, here is a print of msg->buf.
(gdb) set print elements 1024 (gdb) print msg->buf $3 = 0x7f528fbe50a0 "SIP/2.0 487 Request Terminated\r\nFrom: sip:7324231212@66.6.136.41;user=phone;tag=ff754700ff76ff10ff00003048ff62ff\r\nTo: sip:234805449114@70.34.96.20:5060;user=phone;tag=774fdcea2960b2b7\r\nServer: VOS2009 V2.1.1.5\r\nCSeq: 1 INVITE\r\nCall-ID: 4e744700d676b71080000030488062e0@MERA3\r\nContact: sip:234805449114@208.38.165.139:5060\r\nMax-Forwards: 70\r\nContent-Length: 0\r\nTH: uch\r\n\r\n"
I do not see a Via header here at all, though I do not know if that is because the proxy has stripped it off by this point, so I won't comment on the cause.
The core file is available if anyone is interested, but I am not going to obnoxiously attach it like last time. :-)
Cheers,
-- Alex
Hello,
missing via is really strange. Do you have error messages regarding missing via? kamailio core should complain about it.
Crash happens in timer, so it is impossible to see received message. Just to doublecheck, is the mask ip same as your server ip?
Cheers, Daniel
On 10/15/10 2:34 AM, Alex Balashov wrote:
In Kamailio 3.1.0, I get an occasional crash that appears to be due to topoh. Here is the backtrace from the core file, though the binary was not compiled with debug symbols and so some things have definitely been optimised out:
Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 1024 -u root -g r'. Program terminated with signal 11, Segmentation fault. [New process 11535] #0 th_del_via_cookie (msg=0x7fffcca2bbe0, via=0x0) at th_msg.c:951 951 for(p=via->param_lst; p; p=p->next) (gdb) where #0 th_del_via_cookie (msg=0x7fffcca2bbe0, via=0x0) at th_msg.c:951 #1 0x00007f528da90eb4 in th_del_cookie (msg=0x7fffcca2bbe0) at th_msg.c:972 #2 0x00007f528da97748 in th_msg_sent (data=<value optimized out>) at topoh_mod.c:288 #3 0x00007f528f98d1d7 in send_pr_buffer (rb=0x7f5249acc0d8, buf=0x7f528fbe50a0, len=3) at ../../forward.h:133 #4 0x00007f528f9bdffd in t_retransmit_reply (t=0x7f5249acc018) at t_reply.c:1411 #5 0x00007f528f998c17 in retr_buf_handler (ticks=291591695, tl=0x7f5249acc0f8, p=<value optimized out>) at timer.c:367 #6 0x0000000000513e7f in timer_main () at timer.c:894 #7 0x0000000000464c7b in main_loop () at main.c:1618 #8 0x00000000004674d3 in main (argc=<value optimized out>, argv=0x7fffcca2c638) at main.c:2398
This is not a bug I can easily reproduce, and is probably due to an extremely unusual situation. This particular peer that is being interoperated with has a history of eccentric behaviour that makes no sense. Nevertheless, here is a print of msg->buf.
(gdb) set print elements 1024 (gdb) print msg->buf $3 = 0x7f528fbe50a0 "SIP/2.0 487 Request Terminated\r\nFrom: sip:7324231212@66.6.136.41;user=phone;tag=ff754700ff76ff10ff00003048ff62ff\r\nTo: sip:234805449114@70.34.96.20:5060;user=phone;tag=774fdcea2960b2b7\r\nServer: VOS2009 V2.1.1.5\r\nCSeq: 1 INVITE\r\nCall-ID: 4e744700d676b71080000030488062e0@MERA3\r\nContact: sip:234805449114@208.38.165.139:5060\r\nMax-Forwards: 70\r\nContent-Length: 0\r\nTH: uch\r\n\r\n"
I do not see a Via header here at all, though I do not know if that is because the proxy has stripped it off by this point, so I won't comment on the cause.
The core file is available if anyone is interested, but I am not going to obnoxiously attach it like last time. :-)
Cheers,
-- Alex
On 10/15/2010 04:35 AM, Daniel-Constantin Mierla wrote:
missing via is really strange. Do you have error messages regarding missing via? kamailio core should complain about it.
I did not interpret these as involving a missing Via per se, but yes, I get these quite often from topoh:
ERROR: topoh [th_msg.c:374]: cannot find param in via 2
I did not perceive this to mean a missing Via as much as a missing parameter, though, but it does not say what parameter, nor print the whole header here. I suppose I could modify the source to make it do so, it's just that it only happens occasionally so I would have to wait quite a while.
Just to doublecheck, is the mask ip same as your server ip?
Yes.
On 10/15/10 10:38 AM, Alex Balashov wrote:
On 10/15/2010 04:35 AM, Daniel-Constantin Mierla wrote:
missing via is really strange. Do you have error messages regarding missing via? kamailio core should complain about it.
I did not interpret these as involving a missing Via per se, but yes, I get these quite often from topoh:
ERROR: topoh [th_msg.c:374]: cannot find param in via 2
I did not perceive this to mean a missing Via as much as a missing parameter, though, but it does not say what parameter, nor print the whole header here. I suppose I could modify the source to make it do so, it's just that it only happens occasionally so I would have to wait quite a while.
Just to doublecheck, is the mask ip same as your server ip?
Yes.
there is a conflict in this case. I will try to find a fix for it in the next days, meanwhile, you can use another ip address, can be anything (e.g., private ip), not even existing in your server.
Cheers, Daniel
On 10/15/2010 04:42 AM, Daniel-Constantin Mierla wrote:
there is a conflict in this case. I will try to find a fix for it in the next days, meanwhile, you can use another ip address, can be anything (e.g., private ip), not even existing in your server.
Do you think it is the cause of the crash?
Thanks,
On 10/15/10 10:44 AM, Alex Balashov wrote:
On 10/15/2010 04:42 AM, Daniel-Constantin Mierla wrote:
there is a conflict in this case. I will try to find a fix for it in the next days, meanwhile, you can use another ip address, can be anything (e.g., private ip), not even existing in your server.
Do you think it is the cause of the crash?
could be, as now the module removes the mask ip in some headers.
Daniel
-
Alex Balashov -
Daniel-Constantin Mierla