[Webkit-unassigned] [Bug 175014] Frequent situations where iOS device locks up, requiring a hard reboot when consuming webrtc streams on IOS

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=175014

elbecita <elbexu at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elbexu at gmail.com

--- Comment #34 from elbecita <elbexu at gmail.com> ---
Hi, I am seeing similar behavior. My scenario is:
- Screensharing from Chrome (the presenter is using Chrome).
- The stream goes to Kurento server.
- A viewer starts viewing from Safari (Desktop usually, but I see same behavior testing from iPhone).
So it's: Chrome > Kurento server > Safari (not P2P)


The viewer gets to see the stream, webRTC connection seems ok, but after a while, the browser reloads and I can see a message saying an error happened and that is why the browser reloaded.

I've been trying to debug this, and I see that every time the browser reloads there is a memory issue (I saw this in the Mac Console, in the system.log):
malloc mach_vm_map(size=blabla_some_size) failed (error code=3)
error: can't allocate region

I see this error every single time that a reloads in the browser happens. Sometimes the viewer gets to view, the ICE state of the connection goes to complete and everything goes normal, but most of the time the reload happens.

Is this something others are experiencing? I am a bit blocked now, I don't know where to look at. I was trying to get webrtc stats, check the nackCount or the pliCount, but I haven't detected a pattern. Ideally I would love to at least detect when this is going to happen and stop the viewer and retry, before the reload happens.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180501/29c198d2/attachment.html>