<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.8.4">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#ffffff">
hello Daniel<BR>
<BR>
thanks a lot.<BR>
we actually will start testing 5.0 to migrate to it, but in the meantime it's great if we can patch it on the 4.4<BR>
<BR>
best regards<BR>
david<BR>
<BR>
<BR>
El mar, 28-03-2017 a las 13:37 +0200, Daniel-Constantin Mierla escribió:<BR>
<BLOCKQUOTE TYPE=CITE>
    Hello,<BR>
    <BR>
    I pushed a safety checks to avoid crash in this situation. I will have to investigate deeper why it got to this state, but for now the fix should avoid this crash in a similar situation. You have to use the latest branch 4.4 or backport the patch e20b38e0084c1f89c43a921a8a2affbea060aaa5 to your version.<BR>
    <BR>
    Cheers,<BR>
    Daniel<BR>
    <BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    On 28/03/2017 12:15, David Escartín Almudévar wrote:<BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE TYPE=CITE>
        hello Daniel<BR>
        <BR>
        it happened only once as far as i know, i tried to duplicate by myself but i couldnt create the sipp scenario<BR>
        i will try to duplicate it setting the octal parameters in hex escaped by % in the SIP uris to see if i can, but i didnt have time yet<BR>
        <BR>
        in the meantime here you have the information <BR>
        <BR>
        (gdb) frame 6<BR>
        #6  0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679<BR>
        2679 he=dns_get_he(name, dns_flags);<BR>
        (gdb) p *name<BR>
        $1 = {s = 0x0, len = 0}<BR>
        (gdb) p *port<BR>
        $2 = 5080<BR>
        <BR>
        thanks a lot and regards<BR>
        david<BR>
        <BR>
        <BR>
        <BR>
        El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla escribió:<BR>
        <BLOCKQUOTE TYPE=CITE>
            Hello,<BR>
            <BR>
            did it happen only once, or it can be reproduced?<BR>
            <BR>
            Can you also get from gdb:<BR>
            <BR>
            frame 6<BR>
            <BR>
            p *name<BR>
            <BR>
            p *port<BR>
            <BR>
            <BR>
            Cheers,<BR>
            Daniel<BR>
            <BR>
            <BR>
            <BR>
            On 27/03/2017 16:43, David Escartín Almudévar wrote:<BR>
            <BR>
            <BLOCKQUOTE TYPE=CITE>
                hello Daniel<BR>
                <BR>
                here you have<BR>
                <BR>
                (gdb) frame 1<BR>
                #1  0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535<BR>
                535 *h=dns_hash_no(name->s, name->len, type);<BR>
                (gdb) info locals<BR>
                e = 0x7f69069015b8<BR>
                tmp = 0x7f69069247e0<BR>
                ret = 0x0<BR>
                now = 689922868<BR>
                cname_chain = 0<BR>
                cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n", len = 11210375}<BR>
                __FUNCTION__ = "_dns_hash_find"<BR>
                (gdb) list<BR>
                530 cname_chain=0;<BR>
                531 ret=0;<BR>
                532 now=get_ticks_raw();<BR>
                533 *err=0;<BR>
                534 again:<BR>
                535 *h=dns_hash_no(name->s, name->len, type);<BR>
                536 #ifdef DNS_CACHE_DEBUG<BR>
                537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h);<BR>
                538 #endif<BR>
                539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){<BR>
                <BR>
                <BR>
                <BR>
                thanks a lot and regards<BR>
                david<BR>
                <BR>
                <BR>
                <BR>
                <BR>
                El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:<BR>
                <BLOCKQUOTE TYPE=CITE>
                    Hello,<BR>
                    <BR>
                    the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.<BR>
                    <BR>
                    Can you get with gdb from the core the output of the following commands:<BR>
                    <BR>
                    frame 1<BR>
                    <BR>
                    info locals<BR>
                    <BR>
                    list<BR>
                    <BR>
                    <BR>
                    and send them here on the mailing list.<BR>
                    <BR>
                    Cheers,<BR>
                    Daniel<BR>
                    <BR>
                    On 24/03/2017 14:50, David Escartín Almudévar wrote:<BR>
                    <BR>
                    <BLOCKQUOTE TYPE=CITE>
                        hello all, Daniel<BR>
                        <BR>
                        checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated.<BR>
                        checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string<BR>
                        <BR>
                        <BR>
                        SIP/2.0 487 Request Terminated\r\nFrom: \"881237046977\"<<A HREF="sip:881237046977@79.170.68.185">sip:881237046977@79.170.68.185</A>;user=phone>;tag=B7jgc8jQ4m5pB\r\nTo: <<A HREF="sip:5926053324@79.170.68.186:5060">sip:5926053324@79.170.68.186:5060</A>>;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n<BR>
                        <BR>
                        this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016\213\347: \344\003 i have no idea what they are, because they also seem to be out of the ASCII table ¿?<BR>
                        anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes<BR>
                        <BR>
                        hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario<BR>
                        <BR>
                        <BR>
                        best regards<BR>
                        david<BR>
                        <BR>
                        <BR>
                        <BR>
                        El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:<BR>
                        <BLOCKQUOTE TYPE=CITE>
                            hello all <BR>
                            <BR>
                            we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint.<BR>
                            a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed<BR>
                            <BR>
                            Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header<BR>
                            Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11<BR>
                            <BR>
                            <BR>
                            the backtrace of the core<BR>
                            (gdb) backtrace<BR>
                            #0  0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210<BR>
                            #1  0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535<BR>
                            #2  0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762<BR>
                            #3  0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102<BR>
                            #4  0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432<BR>
                            #5  0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505<BR>
                            #6  0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679<BR>
                            #7  0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849<BR>
                            #8  0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704<BR>
                            #9  0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766<BR>
                            #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849<BR>
                            #11 0x00000000005197ef in receive_msg (<BR>
                                buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: \"8888888888\"<A HREF="sip:8888888888@7.7.7.7;user=phone"><sip:8888888888@7.7.7.7;user=phone></A>;tag=B7jgc8jQ4m5pB\r\nTo: <A HREF="sip:555555555@8.8.8.8:5060"><sip:555555555@8.8.8.8:5060></A>;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299<BR>
                            #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495<BR>
                            #13 0x00000000004b107a in main_loop () at main.c:1600<BR>
                            #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616<BR>
                            <BR>
                            <BR>
                            i have tried to duplicate the issue, but i dont know how to translate l\337K\016 to a xml notation<BR>
                            i guess this is some weird that cannot be processed for kamailio<BR>
                            <BR>
                            could you please take a look and let me know if you know how to duplicate and fix this crash?<BR>
                            <BR>
                            thanks a lot and regards<BR>
                            david<BR>
                        </BLOCKQUOTE>
                        <BR>
                        <BR>
                        <BR>
<PRE>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<A HREF="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</A>
</PRE>
                    </BLOCKQUOTE>
                    <BR>
<PRE>
-- 
Daniel-Constantin Mierla
<A HREF="http://www.twitter.com/miconda">www.twitter.com/miconda</A> -- <A HREF="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</A>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - <A HREF="http://www.asipto.com">www.asipto.com</A>
Kamailio World Conference - May 8-10, 2017 - <A HREF="http://www.kamailioworld.com">www.kamailioworld.com</A>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<A HREF="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</A>
</PRE>
                </BLOCKQUOTE>
                <BR>
            </BLOCKQUOTE>
            <BR>
<PRE>
-- 
Daniel-Constantin Mierla
<A HREF="http://www.twitter.com/miconda">www.twitter.com/miconda</A> -- <A HREF="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</A>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - <A HREF="http://www.asipto.com">www.asipto.com</A>
Kamailio World Conference - May 8-10, 2017 - <A HREF="http://www.kamailioworld.com">www.kamailioworld.com</A>
</PRE>
        </BLOCKQUOTE>
        <BR>
    </BLOCKQUOTE>
    <BR>
<PRE>
-- 
Daniel-Constantin Mierla
<A HREF="http://www.twitter.com/miconda">www.twitter.com/miconda</A> -- <A HREF="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</A>
Kamailio Advanced Training - May 22-24 (USA) - <A HREF="http://www.asipto.com">www.asipto.com</A>
Kamailio World Conference - May 8-10, 2017 - <A HREF="http://www.kamailioworld.com">www.kamailioworld.com</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>