[libnice] Assert due to wrong transition

[Igor Khomenko]

Thanks guys for your effort,

I installed the latest libnice master on our staging server, did some smoke
testing and luckily it has not broken everything :phew

Then asked other parties to verify on 4G and the very first feedback is
that it started working properly, no crashes so far, which is fantastic

Will do more tests during next couple of days and let you know

thank you

On 23 March 2018 at 20:33, Olivier Crête <olivier.crete at collabora.com>
wrote:

> Hi,
>
> Merged those commits as it was blocked on me, I finally took time to
> review them and merge them straight to the git master. So if you pull now
> you should have them. Please test carefully as there are a lot of changes!
>
> Olivier
>
> On Fri, 2018-03-23 at 18:40 +0200, Igor Khomenko wrote:
>
> Thanks Fabrice for getting back to me
>
> is there a custom Git branch with the patch I can build from or should I
> port all those changes manually?
>
> At this moment I use latest master -  commits on Nov 28, 2017
>
> thanks
>
>
> On 23 March 2018 at 18:32, Fabrice Bellet <fabrice at bellet.info> wrote:
>
> Hi Igor,
>
> On 03/22/18 at 10:12am, Igor Khomenko wrote:
> > Hi Olivier, Lorenzo
> >
> > I've got all needed logs upon crash, including libnice logs
> >
> > Stacktrace again (the same assert):
> > https://www.dropbox.com/s/jlqtzu0neqlqc8o/janus_libnice_asse
> rt_stacktrace.crash?dl=0
> >
> > logs:
> > https://www.dropbox.com/s/hq1nkeh6w25jsk3/janus.log?dl=0
> >
> > look at the end of janus.log
> > Line N19365 - "(process:17784): libnice-DEBUG: Agent 0x7f6aa000dcf0 :
> > stream 1 component 1 STATE-CHANGE gathering -> connected."
> > this is when crash happened, then autorestart of Janus occurred after
> some
> > time.
> >
> > So all the lines before N19365 are what we are looking for from my
> > understanding,
> > e.g. line N19330 is where assertion failed
> >
> > Please let me know if you need anything else here to identify the root
> > cause and find a proper solution
>
> According to your logs, I think the cause of the problem is that no pair
> is formed by the gathering stage: we have two local IPv4 candidates, and
> we receive a remote IPv6 candidate. A new pair is formed later when we
> start receiving incoming STUN requests. The state of the agent should
> change from GATHERING to CONNECTING there, line 19285 in your janus.log
> file:
>
> (process:17784): libnice-DEBUG: Agent 0x7f6aa000dcf0 : Adding a triggered
> check to conn.check list (local=0x7f6aa00239f0).
> (process:17784): libnice-DEBUG: Agent 0x7f6aa000dcf0 : creating new pair
> 0x7f6aa001a190 state 1
>
> Does this patch help in your case : https://phabricator.freedeskto
> p.org/D1889
> And more precisely, the chunk around line 2967-2968 in conncheck.c that
> replaces
> priv_add_new_check_pair() by priv_conn_check_add_for_candid
> ate_pair_matched()
> at the end of function priv_schedule_triggered_check()  ?
>
> Best wishes,
> --
> fabrice
>
>
>
>
> --
>
> Olivier Crête olivier.crete at collabora.com
>
>


-- 
Igor Khomenko,
CTO @ *QuickBlox*

igor at quickblox.com <taras at quickblox.com>
Q-municate <https://q-municate.com/>: Igor Khomenko

We will be happy to solve your tech issues if you ask ‘quickblox’ tagged
question on StackOverflow http://stackoverflow.com/questions/ask
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20180327/1518b2ae/attachment.html>