From klecker@decoit.de Thu Dec 4 15:56:42 2014 From: Timo Klecker To: sr-users@lists.kamailio.org Subject: Re: [SR-Users] Kamailio Crash when modifying username of Request Uri Date: Thu, 04 Dec 2014 15:56:34 +0100 Message-ID: <033a01d00fd2$7f7ece70$7e7c6b50$@decoit.de> In-Reply-To: <54806D20.8000708@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0412936153==" --===============0412936153== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Daniel, yes, with the production config I still get a core, not with the testing config, though. The last line in log with testing config is: Dec 4 13:28:06 lvm-centos-kamailio1 /sbin/kamailio[8045]: ERROR: [action.c:1572]: run_actions(): WARNING: too many recursive routing table lookups (101) giving up! Dec 4 13:28:06 lvm-centos-kamailio1 /sbin/kamailio[8045]: WARNING: [receive.c:214]: receive_msg(): WARNING: receive_msg: error while trying script But I have 2 cores, each 52M in size from production config. I will bzip them and send them via email. Kind regards, Timo Klecker Von: Daniel-Constantin Mierla [mailto:miconda(a)gmail.com] Gesendet: Donnerstag, 4. Dezember 2014 15:18 An: Timo Klecker; 'Kamailio (SER) - Users Mailing List' Betreff: Re: AW: [SR-Users] Kamailio Crash when modifying username of Request Uri Hello, do you still get a core file? The easiest to troubleshoot is to get the backtrace from the core with gdb. Setting up a testbed requires more resources, not trivial when out of the office. Cheers, Daniel On 04/12/14 14:21, Timo Klecker wrote: Hi Daniel, I was able to recreate the Issue with the newer version (4.1.6). Please find attached Kamailio configuration and sip-invite. (Please change modules path according to installation) The attached Kamailio configuration is a (very) simplified configuration we are running in production. 10.10.207.20 is a server running the attached Kamailio configuration. 10.10.210.71 is a server running sipsak, sending the attached invite. sipsak -s sip:10.10.207.20:5060 -f invite.txt The crash seems to occur due to a missing exit of the configuration loop. So to get rid of the crash I would break the loop if $rU equals null after modification in MODIFY_NUMBER. The issue now simplifies to: You cannot empty $rU when a password is set, because the URI becomes invalid due to missing @: bad uri Dec 4 13:27:50 /sbin/kamailio[8043]: NOTICE: