38.32 KB, image/png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20151103004217 Steps to reproduce: 1. Visit this three.js demo: http://mrdoob.neocities.org/001 2. Try zooming out 3 or 4 times Actual results: All tabs are 'crashed'. Browser console shows: LoginManagerContent:Couldn't parse origin for about:blank [LoginManagerContent.jsm:1178] I'm not sure if that's before or after the crash, though. Expected results: Tabs shouldn't crash, it should just zoom out.
Do you have a crash report for this crash? See about:crashes.
https://crash-stats.mozilla.com/report/index/82450ef0-2cc4-465f-8493-24cec2151111 It might be worth pointing out that the whole page starts slowing down. You can see the cube spinning slower until it crashes.
That crash report doesn't have much to go on. :( I tried reproducing in a current nightly debug build on Mac, but I just got the "slower and slower" behavior, no crash. That said, I expect this is a graphics issue, and the fact that the "slower and slower" behavior affects all applications, not just Firefox, indicates that we're hosing the GPU at least...
Created attachment 8686095 [details] Screenshot of Google Chrome providing more information Indeed, this happens with Google Chrome as well. However, it only crashes the current tab and provides information about what went wrong (WebGL crashed)
How do you zoom out?
Use the browser's zoom functions. The page itself doesn't change (apart from possible Aliasing changes), but the canvas size grows, as the three.js creator points out: https://twitter.com/mrdoob/status/664497227637878784
> How do you zoom out? Command + '-' on Mac, for example.
I can reproduce More reproducible STR: 1. Set preferences zoom.minPercent = 5 toolkit.zoomManager.zoomValues = 0.05, .3,.5,.67,.8,.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3 2. Restart 3. Open the site http://mrdoob.neocities.org/001 4. Zoom out ~5% Actual Results: Tab srashes bp-9298633c-3679-486d-bd1c-414782151112
Can you set environment variables MOZ_GL_DEBUG, MOZ_GL_DEBUG_ABORT_ON_ERROR to 1 and run the build from this try run (once it's done building) and try to reproduce? https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d1d7c4b3776
Sorry, make that this build instead: https://treeherder.mozilla.org/#/jobs?repo=try&revision=51132d3f624a
I suspect we're failing to create the texture for drawing into and not handling that properly. Sounds like an area nical is looking at.
looking at crash data this seems to be a regression in firefox 41.0 - the mozilla::gl::GLContext::MakeCurrent signature is 60% on android and 40% windows, and on #48 on release atm. many of the crashes reports contain a GraphicsCriticalError field similar to the following: |[GFX1]: [D3D11] 2 CreateTexture2D failure Size(1680,939) Code: 0x8007000e|[GFX1]: [D3D11] 2 CreateTexture2D failure Size(1680,939) Code: 0x8007000e|[GFX1]: Failed 2 buffer db=0x00000000 dw=0x00000000 for 0, 79, 1680, 939 many user comments reference google maps in the reports.
0x8007000e are out of memory messages...
Lots of these reports with this signature are crashing on a jemalloc-poisoned address indicating it's likely a use-after-free.
(In reply to Daniel Veditz [:dveditz] from comment #14) > Lots of these reports with this signature are crashing on a > jemalloc-poisoned address indicating it's likely a use-after-free. Yes. I don't think we can do anything about this without properly fixing bug 1224199.
To be clear, this bug is pretty much a dupe of bug 1224199. I am not marking it as such because its currently getting more attention than bug 1224199. To fix it we need to invert the ownership of GLScreenBuffer and GLContext, in order to be able to let textures have strong references to their GLContext (currently not possible because GLContext owns a ScreenBuffer which owns a SurfaceFactory, which owns textures, so it creates a cycle). That's a change that would be best operated (or at least vetted) by someone who owns the gl code (Jeff and Dan are needinfo'ed in bug 1224199).
sec-high and blocking/dupe of a crash bug 1224199.
Too late for a fix in 46, but we could still take a patch for 47 with sec-approval.
Looks like there is a patch on bug 1224199, I'll comment there but keep tracking here.
This landed on central (bug 1224199 comment 22) and is awaiting uplift to 47.
(In reply to Milan Sreckovic [:milan] from comment #20) > This landed on central (bug 1224199 comment 22) and is awaiting uplift to 47. That was uplifted to 47. We need to verify that this no longer repros, or re-evaluate. Does this still crash for you on Nightly?
Not crashing for me anymore using FirefoxDev 48.0a2 (2016-05-09).
This landed without sec-approval so it didn't get flagged for branches. We should have investigated whether to take this sec-high security bug on ESR45.
Well let's investigate it now. Looks like we did try to merge a patch (and it failed) in bug 1224199. Jeff can you request sec-approval if that's what should happen? I'll also comment in the other bug.
Fixed in bug 1224199 for esr45.2.0
We should be done here. We'll do a better job with handling the sec- aspect in the future. This one ended up pear-shaped.
Crash volume for signature 'mozilla::gl::GLContext::MakeCurrent': - nightly (50): 356 - aurora (49): 1 Affected platform: Windows
Can you have a look at the reports in crash-stats? There are still crashes on 49.0b1 for both fennec and Firefox. We could file a new bug for those crashes if that seems best.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1287444#c18, the crash has been fixed in 50, probably by bug 1286459, but I'm trying to confirm it with a reporter who was able to reproduce the crash.
For 49.0b6: 3 crashes for desktop, 27 for fennec. We are now heading into beta 9 later this week but could still take a patch if these remaining crashes are still sec-high, and if it seems worth the risk.
Too late to fix in 50.1.0 release