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'

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

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.

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

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?

(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?

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.

> Is that a Socorro bug? No, annotations are a client-side fix.

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

(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.

That bug is already filed as bug 929012.

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

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

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.

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.

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

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.

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.

(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.

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.

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

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.