<div dir="ltr">Hello Joshua,<div>Thank you for your response. It was important for us to make sure this fix is harmless. </div><div><br></div><div>We will wait for someone to fix it. If you need any assistance we are here. This issue occurs quite often in our environment.</div><div><br></div><div>Yaron.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 12, 2014 at 5:16 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Yaron Nachum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Asterisk users and developers,<br>
The last few weeks we had several crashes on live asterisks running<br>
versions  12.2.0rc1 / 12.6.1 with PJPROJECT versions 2.1.0 / 2.2.1. We<br>
opened a ticket - ASTERISK-24471.<br>
<br>
After investigating the issue I can say that the scenario is a CANCEL<br>
being received while handling ANSWER and before generating the 200OK<br>
response.<br>
<br>
Looking at the core file we see that the problem is in<br>
- pjsip/src/pjsip/sip_<u></u>transaction.c line 3158 :<br>
         PJ_ASSERT_RETURN(event->type == PJSIP_EVENT_TX_MSG &&<br>
event->body.tx_msg.tdata == tsx->last_tx,<br>
                          PJ_EINVALIDOP);<br>
<br>
After investigating further I came to a conclusion that the second<br>
expression fails (marked with yellow), and that causes the Asterisk to<br>
crash.<br>
<br>
I have already removed the expression and logged whenever this<br>
expression fails. It seems to work fine. Since the change it the<br>
happened several times, the application didn't crash and going over the<br>
debug it seems that the call was handled fine.<br>
<br>
Can anyone tell what is the purpose of this expression? Any explanation<br>
why this expression fails in the above scenario?<br>
</blockquote>
<br></div></div>
PJSIP is written with assertions in various places which check various conditions to make sure that things are as expected. In the above scenario what's happening is that the CANCEL is coming in and changing the transaction so when the answer is sent (which occurs after handling the CANCEL) it is not in the expected state and it asserts. It's safe to do as you've done since the operation will do nothing, but that's not a viable fix to push upstream as it's a result of an implementation detail with chan_pjsip. The fix will occur in chan_pjsip once the issue is handled.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
-- <br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
              <a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
  <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-<u></u>users</a><br>
</font></span></blockquote></div><br></div>