1223810 - (CVE-2016-2828) Crash when zooming out on a three.js demo

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[jomo]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Do you have a crash report for this crash?  See about:crashes.

Comment 2

[jomo]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[jomo]

Attachment: 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)

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

How do you zoom out?

Comment 6

[jomo]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

> How do you zoom out?

Command + '-' on Mac, for example.

Comment 8

[Alice0775 White]

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

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Sorry, make that this build instead: https://treeherder.mozilla.org/#/jobs?repo=try&revision=51132d3f624a

Comment 11

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 12

[[:philipp]]

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: 
|[0][GFX1]: [D3D11] 2 CreateTexture2D failure Size(1680,939) Code: 0x8007000e|[1][GFX1]: [D3D11] 2 CreateTexture2D failure Size(1680,939) Code: 0x8007000e|[2][GFX1]: Failed 2 buffer db=0x00000000 dw=0x00000000 for 0, 79, 1680, 939

many user comments reference google maps in the reports.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

0x8007000e are out of memory messages...

Comment 14

[Daniel Veditz [:dveditz]]

Lots of these reports with this signature are crashing on a jemalloc-poisoned address indicating it's likely a use-after-free.

Comment 15

[Nicolas Silva [:nical]]

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

Comment 16

[Nicolas Silva [:nical]]

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

Comment 17

[Milan Sreckovic [:milan] (needinfo for best results)]

sec-high and blocking/dupe of a crash bug 1224199.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix in 46, but we could still take a patch for 47 with sec-approval.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like there is a patch on bug 1224199, I'll comment there but keep tracking here.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

This landed on central (bug 1224199 comment 22) and is awaiting uplift to 47.

Comment 21

[Kelsey Gilbert [:jgilbert]]

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

Comment 22

[jomo]

Not crashing for me anymore using FirefoxDev 48.0a2 (2016-05-09).

Comment 23

[Kelsey Gilbert [:jgilbert]]

Thanks!

Comment 24

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 25

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 26

[Liz Henry (:lizzard) (relman/hg->git project)]

Fixed in bug 1224199 for esr45.2.0

Comment 27

[Kelsey Gilbert [:jgilbert]]

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.

Comment 28

[Calixte Denizet (:calixte)]

Crash volume for signature 'mozilla::gl::GLContext::MakeCurrent':
  - nightly (50): 356
  - aurora (49): 1

Affected platform: Windows

Comment 29

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 30

[Marco Castelluccio [:marco]]

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.

Comment 31

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 32

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Too late to fix in 50.1.0 release