Closed Bug 1228287 Opened 5 years ago Closed 5 years ago
crash in @0x0 | mozilla::gl::GLContext::Init
This bug was filed from the Socorro interface and is report bp-bad6c609-ed56-48cf-a90d-b46682151125. ============================================================= Crashing Thread Frame Module Signature Source 0 @0x0 1 xul.dll mozilla::gl::GLContext::InitWithPrefix(char const*, bool) gfx/gl/GLContext.cpp 2 xul.dll mozilla::gl::GLContextWGL::Init() gfx/gl/GLContextProviderWGL.cpp 3 xul.dll mozilla::gl::GLContextProviderWGL::GetGlobalContext() gfx/gl/GLContextProviderWGL.cpp 4 xul.dll mozilla::gl::WGLLibrary::EnsureInitialized() gfx/gl/GLContextProviderWGL.cpp 5 xul.dll mozilla::gl::GLContextProviderWGL::CreateHeadless(mozilla::gl::CreateContextFlags) gfx/gl/GLContextProviderWGL.cpp 6 xul.dll gfxPlatform::GetSkiaGLGlue() gfx/thebes/gfxPlatform.cpp 7 xul.dll mozilla::dom::CanvasRenderingContext2D::DrawImage(mozilla::dom::HTMLImageElementOrHTMLCanvasElementOrHTMLVideoElementOrImageBitmap const&, double, double, double, double, double, double, double, double, unsigned char, mozilla::ErrorResult&) dom/canvas/CanvasRenderingContext2D.cpp 8 xul.dll mozilla::dom::CanvasRenderingContext2D::DrawImage(mozilla::dom::HTMLImageElementOrHTMLCanvasElementOrHTMLVideoElementOrImageBitmap const&, double, double, mozilla::ErrorResult&) dom/canvas/CanvasRenderingContext2D.h 9 xul.dll mozilla::dom::CanvasRenderingContext2DBinding::drawImage obj-firefox/dom/bindings/CanvasRenderingContext2DBinding.cpp 10 xul.dll mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*) dom/bindings/BindingUtils.cpp 11 @0x876c488 12 @0xffffff87 this windows crash signature started showing up in 43.0a2 builds, and now in all 43 beta builds as well (interestingly no nightly builds in crash stats at all though). this is at #14 on the crash score board for early 43.0b6 data.
This is not a supported configuration. Accelerated, non-D2D canvas, on top of WGL. For example, 0x8086/0x27a2 devices are fully blocklisted, composition and content, which should leave us in cairo content, Skia canvas, but not SkiaGL canvas. One option is that these are all with forced preferences, but we will double check if it's possible to end up in this configuration with the default preferences, just due to blocklisting.
If this doesn't change the crash stats, we have people out there that are setting the preference, forcing canvas acceleration (they actually need to type in the preference name, it doesn't show up on windows by default).
Assignee: nobody → milan
Pretty sure we don't need this patch, but it won't hurt (fixed a typo.)
Attachment #8692617 - Flags: review?(bgirard) → review+
Looking at GPU chipsets, more than 80% of these crashes are happening for users with Intel Generation 3 cards (GMA950/3100/3150). Looking at GPU drivers, the majority are using very old drivers (3 - 10 years old) with only one report coming from a user with an Intel driver from 10 months ago. Given this data it's not entirely surprising that we don't see this on Nightly - those users tend to skew towards more modern hardware/drivers.
could this speculative patch be uplifted to aurora then, in order to be able to gauge its effects? (there is enough crash volume on 44.0a2 to qualify if this fix helps within a matter of days)
Sure. I still expect that the users are just forcing this preference, and that we'd only see the drop in crashes if we ignored it, but it is simple enough a patch. Let's have it successfully stick on central, and then I'll ask for aurora uplift. https://treeherder.mozilla.org/#/jobs?repo=try&revision=91ef3a348e1d
I don't see these in 45, so let's uplift to 44.
Comment on attachment 8692617 [details] [diff] [review] Speculative, barrier for switching to accelerated Skia without a pref. r=benwa Approval Request Comment Small volume crash, but a safe patch. I'm not sure if we switched trains yet, but the uplift is meant for 44.
Attachment #8692617 - Flags: approval-mozilla-aurora?
Comment on attachment 8692617 [details] [diff] [review] Speculative, barrier for switching to accelerated Skia without a pref. r=benwa This has been in Nightly for 2 weeks, crash fixes are good. Taking it for Aurora44.
Attachment #8692617 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://crash-stats.mozilla.com/report/index/95d69f20-c135-4cc8-9705-0fdf02160126 Happened after upgrading to Firefox 44, right after I tried to change a webpage to 3D View. After Firefox crashed and restarted, I tried to do to exact same actions but this time I get the "Could not initialize Tilt" error.
I imagine this is because we detected crash in WebGL and disabled it. Without WebGL enabled, you wouldn't be able to get the tilt functionality. You can check by going to about:support, Graphics section, and looking at the WebGL Renderer field. What does it say?
(In reply to Milan Sreckovic [:milan] from comment #15) > I imagine this is because we detected crash in WebGL and disabled it. > Without WebGL enabled, you wouldn't be able to get the tilt functionality. > You can check by going to about:support, Graphics section, and looking at > the WebGL Renderer field. What does it say? I have no such field. Though I do have "Direct2D enabled" and it says it's blocked for my video adapter driver version. "DirectWrite enabled" is "false (6.2.9200.17568)" "Supports Hardware H264 Decoding" is "No; Hardware video decoding disabled or blacklisted" "(#0) Assert" is "D3D11 device creation failed: 0x887a0004" "(#1) Error" is GLContext is disabled due to a previous crash"
Right - that would confirm that you now have WebGL disabled because of the previous crash. The error we get from Windows is basically "that is not supported by your device or driver". Do you have an option of updating the driver?
(In reply to Milan Sreckovic [:milan] from comment #17) > Right - that would confirm that you now have WebGL disabled because of the > previous crash. The error we get from Windows is basically "that is not > supported by your device or driver". Do you have an option of updating the > driver? I tried it yesterday. Unfortunately mine is the latest one there is.. I checked in Intel website. Thing is, 3D View DID WORK in previous Firefox versions. Didn't change my video drivers since about 2 years ago. Does that makes sense?
We do cache the information, so it is possible that we have a false positive in your case. A quick way to try is to use a new profile (https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles), without any of your preferences, add-ons, etc., and see if the functionality comes back.
C(In reply to Milan Sreckovic [:milan] (PTO 1/29) from comment #19) > We do cache the information, so it is possible that we have a false positive > in your case. A quick way to try is to use a new profile > (https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove- > firefox-profiles), without any of your preferences, add-ons, etc., and see > if the functionality comes back. Created a new profile, still can't enable 3D View on it. Firefox didn't crash this time though. From about:support in the new profile: (#0) Assert D3D11 device creation failed: 0x887a0004 Supports Hardware H264 Decoding No; Hardware video decoding disabled or blacklisted DirectWrite enabled - false (6.2.9200.17568) But as you've mentioned, WebGL is disabled in Firefox 44. Wouldn't it cause 3D View to not work?
Right. We are doing better checking on startup, and your system fails to initialize properly, so everything is disabled.
this crash still occurs frequently in newer versions - should we reopen this bug? https://crash-stats.mozilla.com/search/?product=Firefox&process_type=browser&signature=%3D%400x0+%7C+mozilla%3A%3Agl%3A%3AGLContext%3A%3AInitWithPrefix&date=%3E2016-01-01&_facets=signature&_facets=user_comments&_facets=version&_facets=adapter_vendor_id&_facets=platform_pretty_version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-version
Certainly not sitting as high, dropping to #292, but it does seem to be around.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Looked at it a bit more. While the top function is the same, the problem is different for this bug and the remaining crashes, so I've created bug 1259811 for it - those crashes are all in the initialization of the GL context, rather than in the SkiaGLGlue stack.
Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.