Hi,
Kamailio crashes when we handle a 302 redirect and the reply is a 404.
# kamailio -v version: kamailio 4.4.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 4.9.2
root@14cn5:/home/joel/files#
This works:
softphone1 > kamailio1 > server1 > 302 > kamailio1 > server2 > 200 OK
This crashes:
softphone1 > kamailio1 > server1 > 302 > kamailio1 > server2 > 404 Not Found
I'm attaching debug logs, sip traces and the bt full from backtrace.
IPs:
A.B.C.D = Kamailio IP E.F.G.H = Softphone IP I.J.K.L1 = dispatcher node1 I.J.K.L2 = dispatcher node2
In the config we send INVITE requests to a dispatcher group (very simple config).
Then, in failure_route we have:
``` if (t_check_status("302")) { xlog("L_NOTICE", "Redirecting to TestName: $T_rpl($ct) - M=$rm R=$ru ID=$ci\n"); get_redirects("*"); route(RELAY); } ```
And call get redirected to the address of the contact in the 302.
If the new INVITE to that address gets a 200, all works, if that request gets a 404, Kamailio crashes.
Please let me know if you need more info, this is 100% reproducible on our platform.
Thank you! Joel.
[backtrace.txt](https://github.com/kamailio/kamailio/files/623307/backtrace.txt) [debug.txt](https://github.com/kamailio/kamailio/files/623308/debug.txt) [sip.txt](https://github.com/kamailio/kamailio/files/623309/sip.txt)
please give the core dump to debug this more.
For a useful backtrace, you have to install debugging symbols, respectively kamailio dbg package. Then get the output from gdb for 'bt full' and 'info locals'.
My bad... didn't realize I didn't have dbg installed.
Attached is the real backtrace.
[backtrace-bt_full.txt](https://github.com/kamailio/kamailio/files/625062/backtrace-bt_full.txt) [backtrace-info_locals.txt](https://github.com/kamailio/kamailio/files/625063/backtrace-info_locals.txt)
The backtrace is not pointing correctly to source code -- the lines in the files referred in the first frames of the backtrace are not containing related code.
Can you reproduce the issue and attach the backtrace full from a new core file?
Be sure you use latest version of branch 4.4 (nightly builds from branch 4.4 -- hopefully the debs are still created), it will help being sure it is not something fixed since release of 4.4.4.
Hi Daniel, sorry for the delay, I'm back on this.
I will reproduce and get the backtrace to you ASAP.
Thanks!
Hi Daniel,
Unfortunately I cannot reproduce the issue any more as one of the servers involved is no longer available (the one returning the 404 after the redirect).
Luckily I have another core generated back then which happens to be 10x bigger in size:
-rw------- 1 root kamailio 88371200 Dec 1 07:32 core.kamailio.5062.14cn5.lax1.gogii.net.1480606368 -rw------- 1 root kamailio 8611196928 Dec 1 19:35 **core.kamailio.14300.14cn5.lax1.gogii.net.1480649729**
I'm attaching both "bt full" and "info locals".
Let me know if these are OK or if they are bad too.
[backtrace-bt_full.txt](https://github.com/kamailio/kamailio/files/685940/backtrace-bt_full.txt) [backtrace-info_locals.txt](https://github.com/kamailio/kamailio/files/685941/backtrace-info_locals.txt)
If we can't get anything useful from this core than I think we cannot move forward.
Thanks, Joel.
Hi Daniel,
Did you get a chance to check the attached backtraces?
Thanks, Joel.
Can you try with latest master or version 5.0? There were some changes related to TM transaction structure when handling replies that may have been the reason for your issue as well.
Closed #875.
Reopen if still an issue with latest versions, there were some fixes impacting this.