731767 - Investigate corrupt initial webgl frame following webgl context creation

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

With the patch in bug 713305, we sometimes (maybe once in 3 or 4 attempts) see a corrupted canvas frame immediately following the creation of a WebGL context.

We need to investigate:
 - is this a security problem i.e. is this exposing video memory
 - what's happening?
 - why did we start seeing this with the patch in bug 713305? All it does is trigger a GPU switch when we create a WebGL context. Is it the case, that the GPU switching corrupts a texture held by the compositor, or is this a preexisting bug in our code? the GPU switching should be transparent to us, which makes it hard to see how it could expose a bug in our code.

Comment 1

[Daniel Veditz [:dveditz]]

As a hidden bug it's likely to linger if not assigned to someone. Picking you to start.

Comment 2

[Christian Holler (:decoder)]

Are there steps to reproduce for this? I could look with memory tools (Valgrind/ASan) at it, which might reveal something if the error is in our code.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

STR: use a recent mac with dual AMD/Intel GPUs. Close all apps which might use the discrete GPU. Start Firefox Nightly with no page loaded. Repeat the following steps:
 1. open this WebGL demo in a new tab, and watch carefully to see if the first frame looks corrupt:
     https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/san-angeles/index.html
 2. close that tab.
Repeat steps 1-2 until step 1 produced a corrupt first frame.

The key part is that you have no other 3D stuff going on.

You can use the gfxCardStatus utility to check what card you're on. It will show in the status bar at the top of the Mac OS X screen. You'll see a 'i' if you're on the integrated GPU, and a 'd' if you're on the discrete GPU. Step 1 should switch you to 'd' and step 2 should switch you back to 'i'.

It is possible that valgrind/asan might catch something here. Especially, valgrind might catch an uninitialized value being used (I don't expect that asan could catch that).

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Test page:

  http://people.mozilla.org/~bjacob/poc/poc-bug731767-corrupt-first-frame.html

Comment 5

[Daniel Veditz [:dveditz]]

Assigning to decoder to follow up on comment 2

Comment 6

[Christian Holler (:decoder)]

I remember being told that this is Mac OSX only. Unassigning myself and I don't have any such system. Maybe cdiehl can run this through an ASan build on OSX?

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Christophe do you have time to run this through Asan on OSX as per comment 6?

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

We haven't seen that bug again recently. It's possible that it just went away. Also, if, as I am afraid, it is a driver issue, then ASAN won't help.

Comment 9

[Christoph Diehl [:posidron]]

Have reproduced the above steps 10 times but couldn't identify any distortions. The animation played fine which faded in with black frames.

The corrupt-first-frame test also indicated no corrupt frames.

gfxCardStatus switched immediately to discrete mode after opening Firefox and remained in discrete mode even after closing a tab. It switched back to integrated mode as Firefox got closed.

(This was tested also with the Apple Thunderbolt Display separately.)


Switching to integrated mode after closing a tab caused a Kernel Panic.


MacBook Pro 2012
CPU: 2.6 Ghz i7
RAM: 16GB

Vendor ID0x10de
Device ID0x fd5
WebGL Renderer: NVIDIA GeForce GT 650M 
OpenGL Engine: 2.1 NVIDIA-8.0.51
GPU Accelerated Windows: 1/1 OpenGL

ProductName:	Mac OS X
ProductVersion:	10.8
BuildVersion:	12A269

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Christoph Diehl [:cdiehl] from comment #9)
> Switching to integrated mode after closing a tab caused a Kernel Panic.

Do you mean manually switching using gfxCardStatus, or do you mean the automatic reverting to integrated graphics once the GC destroys the last WebGL context?

Comment 11

[Christoph Diehl [:posidron]]

Correct, manually. I was just curious about what would happen in that case.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Alright. Then that just sounds like not something that we need to worry about. Let's call this bug a WORKSFORME.