[OpenSIPS-Devel] Can't get 2.3 running with voiptests properly

[Bogdan-Andrei Iancu]

Hi Maxim,

Sorry for the delay, finally back on tracks after ClueCon,

And thank you for your latest data (especially for the "trap" output) - 
I have a good lead on what might be the problem. Expect the fix soon.

Best regards,

Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com

OpenSIPS Bootcamp 2017, Houston, US
   http://opensips.org/training/OpenSIPS_Bootcamp_2017.html

On 08/19/2017 01:39 AM, Maxim Sobolev wrote:
> Hi Bogdan, any luck looking into this issue? Looks like a serious 
> problem with 2.3 / master to me. Backing out the commit in question 
> fixes it for us.
>
> -Max
>
> On Mon, Aug 7, 2017 at 12:09 PM, Maxim Sobolev <sobomax at sippysoft.com 
> <mailto:sobomax at sippysoft.com>> wrote:
>
>     Bogdan, I've collected some "opensipsctl trap" output here for
>     you, see line 2611 onwards:
>
>     https://travis-ci.org/sippy/voiptests/jobs/261951017
>     <https://travis-ci.org/sippy/voiptests/jobs/261951017>
>
>     This is 10 seconds after starting the test, CANCELs arrive at
>     about 2-3s mark, so it's well into "dead zone". Yet, I see some
>     CANCEL messages in the traces, so it looks like some locking issue
>     indeed.
>
>     Please let me know if it helps or if you need any more debug. For
>     the time being, I am successfully running with 2.3 and master by
>     reverting change 1eb4ec0f78f43f6ff546de49bc72e513876fb86b
>
>     -Max
>
>     On Wed, Aug 2, 2017 at 8:03 AM, Bogdan-Andrei Iancu
>     <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>         Thank you Maxim for your troubleshooting.
>
>         If you say this code makes a difference in your test, I have
>         the say that the newly added locking may do the "blocking" .
>         To see if this is true, while OpenSIPS is "blocked" could you
>         run several times the "opensipsctl trap" ?
>
>         Best regards,
>
>         Bogdan-Andrei Iancu
>            OpenSIPS Founder and Developer
>            http://www.opensips-solutions.com
>         <http://www.opensips-solutions.com>
>
>         OpenSIPS Bootcamp 2017, Houston, US
>            http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>         <http://opensips.org/training/OpenSIPS_Bootcamp_2017.html>
>
>         On 08/02/2017 03:59 AM, Maxim Sobolev wrote:
>>         Hi Bogdan & Co, I think I've narrowed down failure to a
>>         specific revision in the 2.3 branch, see
>>         https://travis-ci.org/sippy/voiptests/builds/260009545
>>         <https://travis-ci.org/sippy/voiptests/builds/260009545>:
>>
>>         commit 1eb4ec0f78f43f6ff546de49bc72e513876fb86b
>>         Author: Bogdan-Andrei Iancu <bogdan at opensips.org
>>         <mailto:bogdan at opensips.org>>
>>         Date:   Thu Mar 9 15:37:01 2017 +0200
>>
>>             Added support for dynamic branch manipulation
>>
>>             New functions were added to allow remote injecting of new
>>         branches into an ongoing transaction:
>>             * t_inject_branches(source, flags) - injects new branches;
>>             * t_wait_for_new_branches() - instruct transaction to
>>         wait more for possible new injections.
>>
>>         Looking at the diff in question, the following piece of code
>>         looks suspicious, but it might be something else from that
>>         change:
>>
>>         @@ -1244,7 +1301,18 @@ inline static int w_t_relay( struct
>>         sip_msg  *p_msg , char *proxy, char *flags)
>>
>>         update_cloned_msg_from_msg( t->uas.request, p_msg);
>>
>>         -               ret = t_forward_nonack( t, p_msg, p);
>>         +               if (route_type==FAILURE_ROUTE) {
>>         +                       /* If called from failure route we
>>         need reset the branch counter to
>>         +                        * ignore the previous set of
>>         branches (already terminated) */
>>         +                       ret = t_forward_nonack( t, p_msg, p,
>>         1/*reset*/);
>>         +               } else {
>>         +                       /* if called from request route and
>>         the transaction was previously
>>         +                        * created, better lock here to avoid
>>         any overlapping with
>>         +                        * branch injection from other
>>         processes */
>>         + LOCK_REPLIES(t);
>>         +                       ret = t_forward_nonack( t, p_msg, p,
>>         1/*reset*/);
>>         + UNLOCK_REPLIES(t);
>>         +               }
>>                         if (ret<=0 ) {
>>         LM_ERR("t_forward_nonack failed\n");
>>                                 ret = t_relay_inerr2scripterr();
>>         @@ -1262,7 +1330,8 @@ route_err:
>>
>>         The revisions right before that work, none after does.
>>         Hopefully it will give you some clues. Let me know if any
>>         other info is needed.
>>
>>         -Max
>
>
>
>
>     -- 
>     Maksym Sobolyev
>     Sippy Software, Inc.
>     Internet Telephony (VoIP) Experts
>     Tel (Canada): +1-778-783-0474 <tel:%28778%29%20783-0474>
>     Tel (Toll-Free): +1-855-747-7779 <tel:%28855%29%20747-7779>
>     Fax: +1-866-857-6942 <tel:%28866%29%20857-6942>
>     Web: http://www.sippysoft.com
>     MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
>     Skype: SippySoft
>
>
>
>
> -- 
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
> Skype: SippySoft

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20170821/1895563c/attachment.html>