<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Lucida Console'; font-size:9pt; font-weight:400; font-style:normal;">On Mittwoch, 20. Mai 2009, Christian Koch wrote:<br>
&gt; [..]<br>
&gt; After solving all the performance issues with syslog we now made a<br>
&gt; stress test with memdebug enabled. Now kamailio terminates itself<br>
&gt; (perhaps because memory is corrupted?).<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Hi Christian,<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>yes, this looks like the memory is corrupt, as it aparently crashes in a core function (added content from the log file), which normally should be pretty stable:<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: params (0x81677e0, 15), called from proxy.c: hostent_cpy(148) <br>
May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: params (0x81677e0, 16), returns address 0x8265b20 frag. 0x8265b08 (size=32) on 1 -th hit <br>
May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: params (0x81677e0, 4), called from proxy.c: hostent_cpy(159) <br>
May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: params (0x81677e0, 4), returns address 0x81bcbe8 frag. 0x81bcbd0 (size=4) on 1 -th hit <br>
May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: params (0x81677e0, 8), called from proxy.c: hostent_cpy(182) <br>
May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: params(0x81677e0, 0x8265b20), called from proxy.c: hostent_cpy(185) <br>
May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: freeing frag. 0x8265b08 alloc'ed from proxy.c: hostent_cpy(148) <br>
May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]: params(0x81677e0, (nil)), called from proxy.c: hostent_cpy(187) <br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27684]:<br>
&gt; CRITICAL:core:qm_free: bad pointer (nil) (out of memory block!) - aborting<br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27697]:<br>
&gt; CRITICAL:core:receive_fd: EOF on 12<br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27679]:<br>
&gt; INFO:core:handle_sigs: child process 27684 exited by a signal 6<br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27679]:<br>
&gt; INFO:core:handle_sigs: core was not generated<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Can you configure the kamailio server that it generates a core file? Then take a look to the backtrace where the invalid memory access was done, to verify if its really crashed in the core function, or perhaps some other parts has a problem here. Further informations: http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27679]:<br>
&gt; INFO:core:handle_sigs: terminating due to SIGCHLD<br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27681]:<br>
&gt; INFO:core:sig_usr: signal 15 received<br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27681]: Memory<br>
&gt; status (pkg):<br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27681]: qm_status<br>
&gt; (0x81677e0):<br>
&gt; May 20 15:31:55 AmbriaSip1 /usr/local/sbin/kamailio[27681]:  heap size=<br>
&gt; 1048576<br>
&gt;<br>
&gt; The complete output of the memory status is available here:<br>
&gt; https://rcpt.yousendit.com/690295962/7b39d332264f086b1bf0f134c026fad3<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>From the logs it seems that indeed a log of memory was allocated from the pv core. One of the main callers is pv_parse_ht_name, which is from the htable module. Not sure if this is a valid condition that it allocates that much pkg_mem, Daniel, can you perhaps take a look?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Cheers,<br>
Henning</p></body></html>