Loading https://chat.meatspac.es on FF OS nightly build crashes when it attempts to load the WebRTC getUserMedia prompt?

RESOLVED DUPLICATE of bug 940740

Status

()

Core
Networking: WebSockets
--
critical
RESOLVED DUPLICATE of bug 940740
4 years ago
4 years ago

People

(Reporter: ednapiranha, Unassigned)

Tracking

({crash, regression, reproducible})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [b2g-crash][osrestartcrash], URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
On the latest build of FF OS (1.3.0.0-prerelease) when I go to this page with the browser (not as an installed app) it reboots the phone. I checked the error logs on my GP Peak device and it said: 'Boot Reason = 16'

It loads fine on the stable build since there is no WebRTC support.

Just had the same behaviour confirmed by Dietrich on Nexus 4, so I suspect this is a software issue?
That sounds really bad.

QA Wanted - Can someone confirm this on a Buri device on 1.3? Also, does this reproduce on 1.2?
blocking-b2g: --- → 1.3?
Component: General → WebRTC: Audio/Video
Keywords: qawanted
Product: Firefox OS → Core
(Reporter)

Comment 2

4 years ago
As a note about expected behaviour (assuming WebRTC video streaming is supported) - you should get a WebRTC prompt to allow access to a camera, then it shows your video stream in the site on the lower left hand corner. Then the messages should just stream in one by one. It doesn't get to the message streaming since it seems to be blocked by the WebRTC prompt (at least that's my guess).
(In reply to Jen Fong-Adwent [:ednapiranha] from comment #2)
> As a note about expected behaviour (assuming WebRTC video streaming is
> supported) - you should get a WebRTC prompt to allow access to a camera,
> then it shows your video stream in the site on the lower left hand corner.
> Then the messages should just stream in one by one. It doesn't get to the
> message streaming since it seems to be blocked by the WebRTC prompt (at
> least that's my guess).

We actually haven't landed gUM camera support yet for 1.3 - it's going to land shortly. However, we shouldn't be hitting an OS restart crash here when trying to prompt for gUM in an unsupported format. I'm wondering if this problem is present on 1.2.
Severity: normal → critical
Keywords: crash, reproducible
Whiteboard: [b2g-crash][osrestartcrash]

Updated

4 years ago
QA Contact: mvaughan
There are some bugs waiting to land before PeerConnection and gUM video are available on 1.3; bug 853356, 945066,  and a few others.  It shouldn't crash, but it won't work right now either.
(Reporter)

Comment 5

4 years ago
I've tested this without the WebRTC prompt and can confirm it is a web socket issue when socket.io is loading the incoming data. Once the incoming data attempts to come in, the system reboots.
Jen, can you provide a simplified testcase?

Comment 7

4 years ago
This issue DOES reproduce on the 12/06 1.3 build. The phone freezes and then restarts. I attached a logcat that spans from loading the web page until the phone has completed restarting.

This issue does NOT reproduce on the 12/06 1.2 build. The web page loads with posts from different users; no freezing or crashing.

- 1.3 Build -
Environmental Variables:
Device: Buri v1.3 COM RIL
BuildID: 20131206040203
Gaia: 8fca2ca67e8a6022fe6ed8cb576e5d59dfb5237f
Gecko: 1401e4b394ad
Version: 28.0a1
Firmware Version: 20131115
RIL Version: 01.02.00.019.102
Keywords: qawanted

Comment 8

4 years ago
Created attachment 8343866 [details]
LogCat of web page causing crash and restart.
Can you get a crash report ID from your device?

https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Getting_crashes_off_the_Device
Keywords: qawanted, regression
(Reporter)

Comment 10

4 years ago
Reduced test case here https://dl.dropboxusercontent.com/u/1913694/test_b2g.html (says 'socket error on nightly' on the url bar before rebooting)
(In reply to Jen Fong-Adwent [:ednapiranha] from comment #10)
> Reduced test case here
> https://dl.dropboxusercontent.com/u/1913694/test_b2g.html (says 'socket
> error on nightly' on the url bar before rebooting)

The reduced test case doesn't use getUserMedia, so this isn't a WebRTC bug. Socket.IO is a cross-platform web socket library, so I think this likely a web sockets crash.
Component: WebRTC: Audio/Video → Networking: WebSockets
there's really nothing actionable here yet on the platform-websockets side.. nightly is happy with it and the websocket code is totally cross platform so that's a pretty decent indicator it isn't in that code. (though not conclusive, of course).

Is there a stack or something that more definitively makes you think this is a ws issue?

Comment 13

4 years ago
Crash Report ID: bp-73532956-7f74-4b37-8cff-397482131206
Keywords: qawanted
CountRecvBytes and CountSentBytes are called on the socket thread, and they call SaveNetworkStats which can only be called on the main thread. The HTTP channel implementation avoids this by using runnables for calling SaveNetworkStats.
(In reply to Matthew Vaughan from comment #13)
> Crash Report ID: bp-73532956-7f74-4b37-8cff-397482131206

Known crash - and we've got a reduced test case now. It's XPCOM crash.
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 940740
You need to log in before you can comment on or make changes to this bug.