<div>these Cisco ATAs are so old, we are maintaining around 300 of these, and a lot of times</div><div>we encounter corrupted SIP messages of which some are fixed by just reboots, other times,</div><div>by upgrading firmwares. </div>
<div><br></div><div>most of the times, kamailio manages to stay afloat in the midst</div><div>of all these corruption except for some instances like the one i&#39;m reporting, it didn&#39;t.</div><div><br></div><div>i am currently getting the latest git and will test.</div>
<div>the last crash we encountered before yesterday is march 30 and before that, january 5.  </div><div>if i manage to upgrade this now, we won&#39;t know if it really works not unless we monitor this</div><div>for at least 3 months :-)</div>
<br clear="all">Kelvin Chua<br>
<br><br><div class="gmail_quote">On Thu, Apr 22, 2010 at 4:47 PM, Daniel-Constantin Mierla <span dir="ltr">&lt;<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Timo,<br>
<br>
thanks for troubleshooting. I committed the patch that moves setting of bind_addr before any error case in populate_leg_info(). I backported to kamailio_3.0 branch as well.<br>
<br>
Kelvin, can you get the lasted git version for branch kamailio_3.0 and test?<br>
<br>
Thanks,<br><font color="#888888">
Daniel</font><div><div></div><div class="h5"><br>
<br>
On 4/22/10 1:21 AM, Timo Reimann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
<br>
Kelvin Chua wrote:<br>
   <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(gdb) bt<br>
#0  0x00002ab61b62779a in update_dialog_dbinfo (cell=0x2ab61c9100f8) at<br>
dlg_db_handler.c:501<br>
     <br>
</blockquote>
This corresponds to<br>
<br>
   SET_STR_VALUE(values+8, cell-&gt;bind_addr[DLG_CALLEE_LEG]-&gt;sock_str);<br>
<br>
so assumingly sip-router crashes when it tries to access the callee&#39;s<br>
bound address&#39;s sock_str...<br>
<br>
<br>
   <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#1  0x00002ab61b628ea8 in dlg_onreply (t=0x7d5228, type=&lt;value optimized<br>
out&gt;, param=&lt;value optimized out&gt;) at dlg_handlers.c:361<br>
#2  0x00002ab617965505 in run_trans_callbacks_internal<br>
(cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,<br>
<br>
(gdb) print cell<br>
$1 = (struct dlg_cell *) 0x2ab61c9100f8<br>
<br>
<br>
<br>
(gdb) print *cell<br>
0}}, bind_addr = {0x88c580, 0x0},<br>
   cbs = {first = 0x0, types = 0}, profile_links = 0x0}<br>
     <br>
</blockquote>
... as supported by the fact that bind_addr&#39;s second field<br>
(DLG_CALLEE_LEG) is 0.<br>
<br>
Why does the segfault happen?<br>
<br>
Let&#39;s trace the code path: The initial error message<br>
<br>
&quot;bad sip message or missing Contact hdr&quot;<br>
<br>
occurred in dlg_handlers.c, line 218, which makes this piece of code&#39;s<br>
surrounding function &quot;populate_leg_info&quot; return prematurely (by means of<br>
&quot;goto error0&quot;). Specifically, this implies that the code at the end of<br>
the function on line 272<br>
<br>
   dlg-&gt;bind_addr[leg] = msg-&gt;rcv.bind_address;<br>
<br>
isn&#39;t carried out anymore, leaving the callee&#39;s bound address associated<br>
with the given dialog unassigned. (This happens to be the only occasion<br>
where the bound address is assigned.) Instead, execution drops back to<br>
the &quot;dlg_onreply&quot; function and proceeds to line 361, thereby calling the<br>
database update function:<br>
<br>
   update_dialog_dbinfo(dlg);<br>
<br>
which directly leads to the segfaulting code location.<br>
<br>
<br>
AFAICS, &quot;update_dialog_dbinfo&quot; is dereferencing a possibly null memory<br>
location at the dialog data in question only, so one way to prevent the<br>
segfault from happening is to move the bound address assignment before<br>
any failing code in the function. This should make sure that some<br>
accessible bound address is stored in any case.<br>
<br>
<br>
Cheers,<br>
<br>
--Timo<br>
   <br>
</blockquote>
<br></div></div><div><div></div><div class="h5">
-- <br>
Daniel-Constantin Mierla * <a href="http://www.asipto.com/" target="_blank">http://www.asipto.com/</a> * <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a> * <a href="http://www.linkedin.com/in/danielconstantinmierla" target="_blank">http://www.linkedin.com/in/danielconstantinmierla</a><br>

</div></div></blockquote></div><br>