1252396 - crash in mozilla::MediaEngineTabVideoSource::InitRunnable::Run

Status: RESOLVED DUPLICATE of bug 1254102

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[Ada [:adalucinet]]

[Affected versions]: latest Nightly 47.0a1 (from 2016-02-29)
[Affected platforms]: Mac OS X 10.11.1, Mac OS X 10.9.5

[Steps to reproduce]:
1. Launch Firefox.
2. Install the latest Firefox Hello Beta 1.1.9 from https://addons.mozilla.org/en-US/firefox/addon/firefox-hello-beta/ 
3. Click on Hello icon (chat bubble with smiley face).
4. Start a conversation, send the conversation link to another person/PC/profile/browser and join it.
5. Wait a couple o seconds or switch to another tab(s).

[Additional notes]:
1. Also reproducible with Hello add-on version 1.1.6, but *not* with version 1.1.2
2. Reproducible with both https://loop-dev.stage.mozaws.net/v0 and https://loop.services.mozilla.com/v0 loop servers.
3. Unable to reproduce with latest Aurora 46.0a2, nor on 44/45 branch where the add-on is not supported.

Comment 1

[Ada [:adalucinet]]

Reports:
bp-ce626368-3caa-4a43-8e39-ff9992160301
bp-a2167563-4f08-4178-ba99-156a82160301
bp-ead1b469-63c4-4b19-929d-716582160301

Comment 2

[Ian Bicking (:ianbicking)]

Maire: can someone on your team look at this?  Mark Banner doesn't see any functional changes in the WebRTC code between 1.1.6 and 1.1.2; but also since it's a hard crash we're assuming it's at the platform level.

Comment 3

[Maire Reavy [:mreavy]]

Hi Ian -- The crash stats tell us very little.  If we can get a crash reported off a debug build (or a stack backtrace off a debug build), that should tell us a bunch.  My devs and I are jammed this week.  So if you or someone on your team can get us this info, that would be give us a jump start on figuring out where the problem is.  Else, I'll ask someone from my team to look at repro'ing the crash next week.

Comment 4

[Ian Bicking (:ianbicking)]

Alexandra: are you able to reproduce and get a crash with a debug build?

Comment 5

[Bogdan Maris, Desktop QA]

I used the latest debug Nightly https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-macosx64-debug/1457002532/ and after I opened a hello conversation the browser crashed. Here is the terminal output from the moment I started the hello conversation: http://pastebin.com/59rVt9gV.

Note that Nightly crashed on other occasions even without starting a hello call, just browsing one or two websites. Also note that if I disable e10s the crash did not occur. Apparently it only crashes with e10s enabled. 
To start a call with e10s enabled just go to preferences, untick 'Enable multi-process Nightly' cancel the Restart Nightly prompt, then start a Hello call. 

Let me know if I can provide more information here since Alexandra will be on PTO until 10th of March.

Comment 6

[Mark Banner (:standard8)]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #5)
> To start a call with e10s enabled just go to preferences, untick 'Enable
> multi-process Nightly' cancel the Restart Nightly prompt, then start a Hello
> call. 

That doesn't start with e10s enabled - that's to disable e10s.

Comment 7

[Mark Banner (:standard8)]

(In reply to Mark Banner (:standard8) from comment #6)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #5)
> > To start a call with e10s enabled just go to preferences, untick 'Enable
> > multi-process Nightly' cancel the Restart Nightly prompt, then start a Hello
> > call. 
> 
> That doesn't start with e10s enabled - that's to disable e10s.

Oh sorry, I missed the not restarting part of this. The simpler way to test with e10s enabled is to set the "loop.remote.autostart" to true.

Note that I filed bug 1254102 on a firm issue with e10s enabled.

Bogdan, could you retry with the pref enabled and avoiding bug 1254102?

Comment 9

[Ada [:adalucinet]]

Crash reproducible on latest 48.0a1 (from 2016-03-10), under Mac OS X 10.11.1, *only* with e10s enabled and 'loop.remote.autostart' set to true: bp-38d20286-888d-4d8a-b123-3c7052160311 

Latest 48.0a1 debug build (Build ID: 20160311025214) output with e10s enabled and 'loop.remote.autostart' set to true, is available here http://pastebin.com/M9RfAxcA

Comment 10

[Mark Banner (:standard8)]

I haven't been able to reproduce this locally, from witching between "normal" remote tabs (i.e. create new tabs, switch between normal remote tabs with various web pages loaded, e.g. youtube, mozilla, google etc).

However, Alexandra and Ian say they can reproduce frequently/easily.

Tentatively putting on the e10s roadmap, as this might stop us enabling it for Loop.

Maire: is the debug information here enough now?

Comment 11

[Maire Reavy [:mreavy]]

The crash report from comment 9 appears to be for an opt build which makes it tough to know the exact cause.  If the crash is reproducible on a debug build, I'd like a crash report from a debug build.  However, I talked to Randell, and he's working on a build for someone who can repro this issue (e.g. Alexandra and/or Ian) to try to see if it fixes the issue.  (There are a limited number of things in this method that could lead to a null deref.)

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

FYI, here's a Try build with a possible fix (note: it will throw a
      NS_WARNING("*** Would have crashed in TabVideoSource::InitRunnable::Run()! ***");
if it would have crashed without this patch).

ada - can you try with this? thanks!

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ab8f3b01688f

Comment 13

[Maire Reavy [:mreavy]]

Ian -- Since you can repro this bug, can you try Randell's build?  (See Comment 12 for details.)  Randell has already done a needinfo to Alexandra, but it'd be helpful for you to try it also. Thanks!

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Attachment: avoid null-deref crash

Possible crash-fix patch; if this works there's a question of why this is needed, but clearly GetOuterWindowWithId() can return null so it should be handled.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

This is a contributing factor to bug 1254102, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1254102#c7

Comment 16

[Ian Bicking (:ianbicking)]

I was only able to reproduce this problem the one day, since then I've been unable to do so.  I'll keep trying it and try the debug build if I can reproduce on Nightly.

Comment 17

[Ada [:adalucinet]]

(In reply to Randell Jesup [:jesup] from comment #12)
> FYI, here's a Try build with a possible fix (note: it will throw a
>       NS_WARNING("*** Would have crashed in
> TabVideoSource::InitRunnable::Run()! ***");
> if it would have crashed without this patch).
> 
> ada - can you try with this? thanks!
> 
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=ab8f3b01688f

With the provided try build [1] and 'loop.remote.autostart' set to true, I hit this crash bd4c6182-4858-4c50-847c-7f3a42160315 when using the same STR, under Mac OS X 10.10.5. With NightlyDebug try build, ‘NightlyDebug quit unexpectedly’ OS X crash report dialog is displayed and no Socorro crash report generated. NightlyDebug output via Terminal can be found here: http://pastebin.com/vfQbjbTj

[1] http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-ab8f3b01688f6f718cd6c95fb6c622118cae5985/try-macosx64/

Comment 18

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Hi, 

I'm seeing the same crash signature with slightly different steps on Ubuntu 14.04.

[Affected versions]:
Nightly 48.0a1, Build ID 20160316030233

[Steps to reproduce]:
1. Open browser and visit a website.
2. Click the Hello button and after the drop-down is displayed, click "Browse this page with a friend".
3. After the guest has joined the call and while in the call, open a new tab and go to about:config.
4. After the call is lost, detach the Hello window and close it.
5. Repeat Step 2 and 3 and observe the browser behavior.

[Expected result]:
- The about:config page is displayed.

[Actual result]:
- Nightly crashes with [@ mozilla::MediaEngineTabVideoSource::InitRunnable::Run ] signature

[Notes]:
- does not occur with e10s disabled
- it is also reproducible with Hello addon 1.2
- https://crash-stats.mozilla.com/report/index/4ee6f439-a829-489b-83c1-d1c062160318

Comment 19

[Maire Reavy [:mreavy]]

@adalucient , @cmuresan -- Since both of you can repro this bug, can you re-test with the latest build of mozilla-central or tomorrow's Nightly?  

After talking with Mark (Standard8), Randell (jesup) and Gian-Carlo (gcp), I think it's likely that this crash is fixed by that patches on Bug 1254102 , which merged to mozilla-central less than an hour ago.  So I'd love to know if either of you can repro this crash with gcp's fix (from Bug 1254102) applied.

If you can re-test and get back to me at your earliest opportunity, I'd really appreciate it. Thanks!

Comment 20

[Ciprian Muresan [:cmuresan], Ecosystem QA]

I have re-tested this issue with the latest build from mozilla-central (Build Id 20160318030236) and it no longer crashes on Ubuntu 14.04. However I am now seeing an extra crash signature on Mac 10.7 and 10.11 with the same build (https://goo.gl/Hp5Q4k)

I have tested this issue further, using the tinderbox build https://goo.gl/M28sT5 and with that the browser no longer crashes, but I'm still seeing a new crash in about:crashes each time I try to reproduce (https://goo.gl/WgsYjV)

Comment 22

[Gian-Carlo Pascutto [:gcp]]

The crash signature matches https://bugzilla.mozilla.org/show_bug.cgi?id=1254102#c0

I will see if I can reproduce on Mac.

Comment 23

[Maire Reavy [:mreavy]]

At this point, I'm very confident this is a dup of Bug 1254102.  If I'm wrong, please reopen.

Given gcp's Comment 22, I think follow up conversations should probably happen on bug 1254102 or on a new bug.

Comment 24

[Ada [:adalucinet]]

(In reply to Maire Reavy [:mreavy] (Plz ni?:mreavy) from comment #19)
> @adalucient , @cmuresan -- Since both of you can repro this bug, can you
> re-test with the latest build of mozilla-central or tomorrow's Nightly?  

Confirming that this issue is no longer reproducible on latest 48.0a1 (from 2016-03-20), under Mac OS X 10.11.1, with both addon versions 1.1.12/1.2 and ‘loop.remote.autostart’ pref set to true.