Closed Bug 869957 Opened 12 years ago Closed 12 years ago

Crash in mozilla::layers::ClientLayerManager::GetBackendName with abort message: "Invalid backend" (with OMTC enabled)

Categories

(Core :: Graphics: Layers, defect)

23 Branch
All
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla23
Tracking Status
firefox22 --- unaffected
firefox23 --- verified

People

(Reporter: Virtual, Assigned: bas.schouten)

References

()

Details

(Keywords: crash, nightly-community, reproducible, Whiteboard: [fixed by relanding bug 830347])

Crash Data

Going to about:support with OMTC enabled (layers.offmainthreadcomposition.enabled;true) crashes the browser. Crashlogs: https://crash-stats.mozilla.com/report/index/bp-d696dcbb-bcac-4c39-bf6e-011382130508 https://crash-stats.mozilla.com/report/index/bp-c9d0606c-d0bf-4098-b65d-318a52130508 https://crash-stats.mozilla.com/report/index/bp-b9b3b0d4-6059-4e62-8bd1-9ff3b2130508 I suspect that landing patches form bug #830347 caused these crashes, because it works fine in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130507 Firefox/23.0 and crashes in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130508 Firefox/23.0
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak | mozilla::layers::ClientLayerManager::GetBackendName(nsAString_internal&) ]
Bas, are you the right person to follow up?
Assignee: nobody → bas
That pref didn't -do- anything before the landing of bug 830347, so it's not quite surprising it worked before :). Could you report your about:support graphics section? I'm guessing we're not correctly dealing with blacklisted cards.
(In reply to Bas Schouten (:bas.schouten) from comment #2) > I'm guessing we're not correctly dealing with blacklisted cards. By the way, why is Mozilla blacklisting so many graphics adapters/drivers that work and are supported by chrome? Is there some fundamental issue with how Mozilla does HA that it has to blacklist so much?
I can reproduce the issue with my Intel GMA 4500MHD. Here is the current breakdown per graphics configuration: VendorID: 0x8086 (Intel), DeviceID: 0x2a42 (GMA 4500MHD), Version: 8.15.10.2869 VendorID: 0x1002 (AMD), DeviceID: 0x6758 (Radeon HD 6670), Version: 9.12.0.0 VendorID: 0x10de (NVIDIA), DeviceID: 0x1205 (GeForce GTX 460), Version: 9.18.13.2000 VendorID: 0x10de (NVIDIA), DeviceID: 0x1251 (Geforce GTX 560M), Version: 9.18.13.1422 More reports at: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak+|+mozilla%3A%3Alayers%3A%3AClientLayerManager%3A%3AGetBackendName%28nsAString_internal%26%29
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: reproducible
Hardware: x86_64 → x86
Summary: Crash in mozilla::layers::ClientLayerManager::GetBackendName (with OMTC enabled) → Crash in mozilla::layers::ClientLayerManager::GetBackendName with abort message: "Invalid backend" (with OMTC enabled)
(In reply to Bas Schouten (:bas.schouten) from comment #2) > That pref didn't -do- anything before the landing of bug 830347, so it's not > quite surprising it worked before :). Could you report your about:support > graphics section? I'm guessing we're not correctly dealing with blacklisted > cards. My graphic card (Radeon HD 7870) isn't blacklisted, but i get also crashes. App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x6818, AdapterSubsysID: 25541458, AdapterDriverVersion: 12.102.3.0 D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ xpcom_runtime_abort(###!!! ABORT: Invalid backend: file e:/builds/moz2_slave/m-cen-w64-ntly-000000000000000/build/gfx/layers/client/ClientLayerManager.cpp, line 377 https://crash-stats.mozilla.com/report/index/bp-47e36c3e-def7-4143-907a-d225d2130508 @ mozalloc_abort(char const* const) | NS_DebugBreak | js::EmptyShape::getInitialShape(JSContext*, js::Class*, js::TaggedProto, JSObject*, unsigned __int64, unsigned int)
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak | mozilla::layers::ClientLayerManager::GetBackendName(nsAString_internal&) ] → [@ mozalloc_abort(char const* const) | NS_DebugBreak | mozilla::layers::ClientLayerManager::GetBackendName(nsAString_internal&) ] [@ mozalloc_abort(char const* const) | NS_DebugBreak | js::EmptyShape::getInitialShape(JSContext*, js::Class*, js::TaggedPro…
Hardware: x86 → All
(In reply to Bas Schouten (:bas.schouten) from comment #2) > Could you report your about:support graphics section? > I'm guessing we're not correctly dealing with blacklisted cards. Sure, but I think blacklisting isn't the main culprit here Graphics Adapter Description - NVIDIA GeForce GTX 460 v2 Adapter Drivers - nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM - 1023 Device ID - 0x1205 Direct2D Enabled - true DirectWrite Enabled - true (6.2.9200.16492) Driver Date - 4-18-2013 Driver Version - 9.18.13.2000 GPU #2 Active - false GPU Accelerated Windows - 8/8 Direct3D 10 Vendor ID - 0x10de WebGL Renderer - Google Inc. -- ANGLE (NVIDIA GeForce GTX 460 v2) AzureCanvasBackend - direct2d AzureContentBackend - direct2d AzureFallbackCanvasBackend - cairo (In reply to Scoobidiver from comment #4) I didn't ask, but you won't be annoyed if I will add you to CC on every my future crash bugs reports, because as I can see, you are the main person of hunting and managing it. :)
(In reply to IU from comment #3) > (In reply to Bas Schouten (:bas.schouten) from comment #2) > > I'm guessing we're not correctly dealing with blacklisted cards. > > By the way, why is Mozilla blacklisting so many graphics adapters/drivers > that work and are supported by chrome? Is there some fundamental issue with > how Mozilla does HA that it has to blacklist so much? We actually accelerate content through Direct2D. That we have to blacklist for very aggressively. Chrome mostly only accelerated composition I believe for web content (outside of Canvas). We also do that, and we blacklist for that a lot less aggressively
I'm not sure this should be considered a regression.. there was a pref before that didn't do anything, now the pref does something and that turns out to crash in some cases :). I agree if someone set the pref that didn't do anything before it will have regressed their experience, but I don't think that qualifies, I'm happy to be convinced otherwise.
Keywords: regression
The reland includes fix for this btw. One thing I should note is I didn't realize people actually had this pref set (since it didn't do anything). I should note there's a couple of performance issues still with OMTC D3D11 and canvas. So you might see problems there, of course on the other hand it's great to have people testing this!
(In reply to Bas Schouten (:bas.schouten) from comment #9) > One thing I should note is I didn't realize people > actually had this pref set (since it didn't do anything). I'm Nightly tester, so it's pretty logical to test all new features, even disabled or hidden. :) But what's more you guys by yourself asked for help in testing OMTC here: https://mozillagfx.wordpress.com/2012/10/06/how-to-help-testing-off-main-thread-compositing/ http://featherweightmusings.blogspot.com/2013/04/the-layers-refactoring-has-landed.html or course it wasn't ready yet on Windows, but new settings can be changed in advance... ;P
(In reply to Bas Schouten (:bas.schouten) from comment #9) > The reland includes fix for this btw. I tested it with latest Nightly and this looks fixed as crashes didn't occur anymore. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130510 Firefox/23.0 ID:20130510041606 ChangeSet:08be63954b6b Someone with privileges can close this bug as FIXED and add to whiteboard [fixed by relanding bug #830347]. Thanks
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by relanding bug 830347]
Target Milestone: --- → mozilla23
Marking status-firefox23:verified based on comment 11. Thanks Virtual.
You need to log in before you can comment on or make changes to this bug.