WebGL canvases of width <= 16 contain uninitialized memory upon creation on HTC One S

RESOLVED FIXED in Firefox 21

Status

()

Core
Canvas: WebGL
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bjacob, Assigned: bjacob)

Tracking

({sec-high})

unspecified
mozilla21
ARM
Android
sec-high
Points:
---

Firefox Tracking Flags

(firefox20 affected, firefox21 fixed, firefox-esr17 unaffected, b2g18 unaffected)

Details

(Whiteboard: [adv-main21+])

Attachments

(2 attachments, 3 obsolete attachments)

Created attachment 661462 [details]
testcase

STR: load testcase

Expected: blank page

Actual: hit reload a few times, see some random junk.

Tested on a HTC One S with a Adreno 225 GPU.
(Assignee)

Updated

6 years ago
Summary: resizing GL canvas leaves junk in the drawing buffer on Android → resizing GL canvas leaves junk on Android
(Assignee)

Updated

6 years ago
Group: core-security
(Assignee)

Comment 1

6 years ago
Created attachment 661464 [details]
testcase

Oh, actually the issue is not with resizing the canvas, it's with scaling it by setting a style size different from the drawing buffer size.
Attachment #661462 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Summary: resizing GL canvas leaves junk on Android → Scaling a WebGL canvas gives junk on Android
(Assignee)

Comment 2

6 years ago
...which makes it more likely to be a gfx/layers bug than a WebGL bug.
Component: Canvas: WebGL → Graphics: Layers
(Assignee)

Comment 3

6 years ago
Created attachment 661465 [details]
testcase

New findings:
 - the drawing buffer itself is corrupted: these random pixels can be read by readPixels, as this testcase shows
 - this has nothing to do with scaled or resized canvases after all
 - this reproduces on a fresh new WebGL context, never resized or scaled
 - this only seems to affect canvases of width <= 16.
Attachment #661464 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Summary: Scaling a WebGL canvas gives junk on Android → WebGL canvases of width <= 16 contain uninitialized memory upon creation on Android
(Assignee)

Comment 4

6 years ago
And so, back to the WebGL component. Sorry for the noise.
Component: Graphics: Layers → Canvas: WebGL
(Assignee)

Updated

6 years ago
Keywords: sec-high
(Assignee)

Comment 5

6 years ago
This is confirmed to be a Adreno driver bug: glClear is called by GLContext::ClearSafely during WebGL initialization, checked with GDB. It just doesn't do its job.
(Assignee)

Comment 6

6 years ago
Michael, this is a bug in the Adreno driver: with a framebuffer object backed by a texture of width <= 16, glClear seems to not take effect. Any info on possible work-arounds / scope of bug / hope of fixes would be greatly appreciated!
(Assignee)

Comment 7

6 years ago
FWIW I stumbled upon this while writing the ATC conformance test (which uses a 16x8 canvas) and this soft-blocks it -- I can still write a conformance test with that bug, but not the one I'd like to.
Blocks: 790712
Can you please let me know the "Version:" of the driver in use here.  I need that to map back into the source internally.

e.g:
E/GeckoConsole(  904): OpenGL LayerManager Initialized Succesfully.
E/GeckoConsole(  904): Version: OpenGL ES 2.0 V@6.0 AU@04.00.04.19.229 (CL@)
E/GeckoConsole(  904): Vendor: Qualcomm
E/GeckoConsole(  904): Renderer: Adreno (TM) 200
E/GeckoConsole(  904): FBO Texture Target: TEXTURE_2D

Also does the issue still manifest with the latest driver from  
https://developer.qualcomm.com/download?  (Search for "Adreno 2xx User-mode Android ICS Graphics Driver (ARMv7)" link in the bottom half of the page).
(Assignee)

Comment 9

6 years ago
Traveling (to Khronos F2F), will be back on Thursday. Jeff, if you want to check this for me, this is the HTC/Adreno phone you had lent me, it's sitting on my desk.
Assignee: nobody → bjacob
Can we get an update here? It has been over three months.
Oops, looks like I dropped this ball. Will look into it on Monday.
Created attachment 702905 [details]
testcase

fixed the testcase in success case
Attachment #661465 - Attachment is obsolete: true
So I tried on a bunch of Adreno phones to see how widespread the problem is:

Does not reproduce:

Otoro
Unagi

Reproduces:

HTC One S
 (Hardware: ville, GPU: Adreno 225)

WebGL blocked on:

HTC "passion"
 (Hardware: mahimahi, GPU: Adreno 200)
HTC "supersonic"
 (Hardware: supersonic, GPU: Adreno 200)
HTC Desire HD
 (Hardware: spade, GPU: Adreno 205)

So, possibly thanks to WebGL being blacklisted on old Adreno drivers, the HTC One S was the only phone on which I could reproduce.

Most importantly, the B2G prototype phones (Otoro and Unagi) are unaffected!

At this point I'm not concerned anymore by this bug; if you want, we can blacklist WebGL on the HTC One S, but that's about it.
Created attachment 702978 [details] [diff] [review]
blacklist WebGL on HTC One S ("ville")
Attachment #702978 - Flags: review?(jgilbert)
Comment on attachment 702978 [details] [diff] [review]
blacklist WebGL on HTC One S ("ville")

Review of attachment 702978 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/android/GfxInfo.cpp
@@ +345,5 @@
>          *aStatus = nsIGfxInfo::FEATURE_BLOCKED_DEVICE;
>          return NS_OK;
>        }
> +
> +      if (mHardware.Equals(NS_LITERAL_STRING("ville"), nsCaseInsensitiveCStringComparator())) {

Equals not StartsWith or Contains, or similar?
Attachment #702978 - Flags: review?(jgilbert) → review+
I think we really want Equals there. Suppose that Zynga gets in the business of making phones next year and names their hardware "farmville" .
(Assignee)

Updated

6 years ago
Summary: WebGL canvases of width <= 16 contain uninitialized memory upon creation on Android → WebGL canvases of width <= 16 contain uninitialized memory upon creation on HTC One S
Build bustage; hotfix consists in dropping the attempt at case-insensitiveness. -1 for our string classes (case-insensitive compares should be easy, they're not).

https://hg.mozilla.org/integration/mozilla-inbound/rev/8f213db8fe7f
Backed out speculatively as the possible cause of android reftest-4 failures (for lack of any better guesses that I could find):
https://hg.mozilla.org/integration/mozilla-inbound/rev/d9d98ffe9ecc
Still failing:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound
also, the reftest failure was a SVG reftest, according to the logs.
https://hg.mozilla.org/mozilla-central/rev/b52b445017c9
https://hg.mozilla.org/mozilla-central/rev/cf4db0037c7e
Status: NEW → RESOLVED
Last Resolved: 6 years ago
status-firefox21: --- → fixed
Resolution: --- → FIXED
[Security Triage] Marking esr17/b2g unaffected as this affected driver may not be used there.Please help with comment's if this was misunderstood for b2g.Thanks
status-b2g18: --- → unaffected
status-firefox-esr17: --- → unaffected
status-firefox20: --- → affected
Whiteboard: [adv-main21+]
Group: core-security
You need to log in before you can comment on or make changes to this bug.