947213 - crash in mozilla::layers::DeprecatedTextureHostBasic::UpdateImpl with e10s tabs on desktop

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Tracy Walker [:tracy]]

This bug was filed from the Socorro interface and is 
report bp-1cf87855-745e-4c68-9dec-a84422131206.
=============================================================

This has exploded into #8 top crasher on Nightly with builds beginning 20131204030203.

Many reports have comments like 'Opened a new tab with "browser.tabs.remote" = true'

Comment 1

[Tracy Walker [:tracy]]

changset prior to first affected builds: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8648aa476eef&tochange=9688476c1544

Comment 3

[Brian Carpenter [:geeknik]]

I'm seeing this crash (and a variation of this crash) with the latest build of Holly (Built from http://hg.mozilla.org/projects/holly/rev/bd9075540b41) in a couple of different places after setting browser.tabs.remote = true.

The first place I'm seeing it is while scrolling down in the Extensions section of about:addons.

The second place I'm seeing it is while scrolling down through one of the following crash reports:
https://crash-stats.mozilla.com/report/index/f8a21ac5-c768-4a2c-a848-f06d02131207
https://crash-stats.mozilla.com/report/index/5df8cf56-c775-4f4e-a644-2b7ea2131207
https://crash-stats.mozilla.com/report/index/54e6f369-9ba3-4c0a-a504-385a42131207
https://crash-stats.mozilla.com/report/index/9f82608a-174a-4596-9e0d-f69da2131207
https://crash-stats.mozilla.com/report/index/ff09154a-91b8-498e-b840-fa3862131207

Unfortunately, I haven't been able to get the crash to happen while running Holly inside WinDBG, so I don't have any other useful information at this time.

Comment 4

[u279076]

This has risen to #3 on Nightly. What's needed to get some developer action on this bug?

Comment 5

[Benjamin Smedberg]

e10s is still pretty experimental, so not much other than put it in the right component and cc some people. We should at least make sure that we're annotating the remote-tabs setting so that we can exclude these from consideration if necessary. Can you file that?

Comment 6

[u279076]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> We should at least make sure that we're annotating the remote-tabs setting so that we can exclude these from
> consideration if necessary. Can you file that?

Is that a Socorro bug?

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This is a crash in the basic compositor. It looks like ShadowLayerForwarder::OpenDescriptor is returning NULL. The most obvious way this could happen is if TShmem and TMemoryImage don't cover all the possible surface types, but maybe something else is returning NULL.

Comment 8

[Benjamin Smedberg]

> Is that a Socorro bug?

No, annotations are a client-side fix.

Comment 9

[Tom S [:evilpie]]

Just something I noticed, OpenDescriptor handles SurfaceDescriptor::TRGBImage as well, but "case" isn't on its own line.

Comment 10

[u279076]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> > Is that a Socorro bug?
> 
> No, annotations are a client-side fix.

Sorry I'm still unsure what component this should go in.

Comment 11

[(not currently active) Ted Mielczarek]

That bug is already filed as bug 929012.

Comment 12

[Semtex]

My crash from today: https://crash-stats.mozilla.com/report/index/1aa35d2a-3f24-4265-815d-ab6d32131213
Triggered by layers.offmainthreadcomposition.force-basic;true
I've browser.tabs.remote" = false

I was checking crash report and I want to see related bug, then Nightly crash again with same crash signature: https://crash-stats.mozilla.com/report/index/d44ace3d-01ef-40ab-9e9a-969a22131213

Comment 13

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Matt or Markus, any chance you guys can take a look at this? It's a high-volume crash in the basic compositor.

Comment 14

[u279076]

This is now the #1 crash on Firefox 28.0a1 @ 9.83% of all browser crashes. It's hard for me to say what this looks like on Firefox 28.0a2 yet as volume is low due to updates being turned off until later today.

Comment 15

[Robert Kaiser]

28.0a1 is out of business, and we don't expect this to spill over into 28.0a2 much as we only advertised e10s for Nightly and not for Aurora (and it's not on by default). It might continue to be an issue with current Nightly, which is 29.0a1.
That said, we apparently know that e10s can cause crashes in gfx as nrc said in bug 947240 comment #4, that might play a role here as well.

Comment 16

[u279076]

Current Rank:
#3 on Nightly at 4.66%
#41 on Aurora at 0.39%
N/A on Beta

Comment 17

[Markus Stange [:mstange]]

I've tried to reproduce this on Mac by activating the Basic Compositor and ran into a different issue which I filed bug 951186 about.

Comment 18

[u279076]

Current 7-day Rank:
 * Firefox 29: 89 crashes (#10 @ 0.83% [-0.41%])
 * Firefox 28: 16 crashes
 * Firefox 27: 1 crash
 * Firefox 26: 0 crashes

This seems to have all but disappeared on Firefox 27 and 28. While it is still technically a topcrash in Firefox 29 it has dropped significantly. Either less people are playing around with e10s or something else has likely mitigated this crash.

Comment 19

[Robert Kaiser]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #18)
> This seems to have all but disappeared on Firefox 27 and 28. While it is
> still technically a topcrash in Firefox 29 it has dropped significantly.
> Either less people are playing around with e10s or something else has likely
> mitigated this crash.

This is expected, I think it never really was on beta or release, e10s is supposed to be used by Nightly users only, and it's usage will of course fluctuate. And people encountering crashes with it will be motivated to turn e10s back off. So this is really a bug that should stay around and block the e10s project.

Comment 20

[Nicolas Silva [:nical]]

Attachment: Don't crash if OpenSurfaceDescriptor returns null

I haven't been able to reproduce the crash on Linux and Windows 7, so I haven't yet found what causes us to get into that state. This patch makes us return early and print a warning if the surface surface we receive is not valid, instead of crashing.

Comment 21

[Nicolas Silva [:nical]]

Attachment: Don't crash if OpenSurfaceDescriptor returns null

Oops, I got the an if condition backward, fixed in this patch.

Comment 22

[Nicolas Silva [:nical]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d97cb0a0873a

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d97cb0a0873a

Comment 24

[u279076]

There are no more crashes reported in Firefox 29.0a1 since this landed. Marking unaffected for Firefox 28 and 27 since e10s is completely unsupported there are this time.