New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 812242 link

Starred by 2 users

Issue metadata

Status: Duplicate
Owner:
Last visit > 30 days ago
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

WebGL - Image corruption due to mismatched textures

Reported by adr...@cambridge-intelligence.com, Feb 14 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36

Steps to reproduce the problem:
1. In our product, use webgl with any chart that has text and images
2. Image corruption appears when the texture is uploaded a second time, for example with load in a new font atlas texture when new glyphs (e.g. unicode) is required

What is the expected behavior?
Text should readable and images aligned and of the same image as requested

What went wrong?
We create multiple texture atlases by drawing images and font glyphs to a canvas element that we then upload to the gpu.  In the attached image you can see that where there should be text there are now images.  These are stored as separate textures and it seems that it has loaded a completely incorrect texture bank.  Not only that but the texture coordinates seem to be wrong.

Did this work before? Yes 64 (current stable)

Does this work in other browsers? Yes

Chrome version: 65.0.3325.51  Channel: beta
OS Version: OS X 10.13.3
Flash Version: 

As this is commercial product as such I can't share an exact example (unless you want to buy a license ;) ).  Its very very important that 65 doesn't go live until this issue is resolved but I will try and see If I can produce a simpler test case you can use.

Thanks
 
expected (chrome 64).png
30.3 KB View Download
broken (chrome 65).png
39.2 KB View Download
I've managed to replicate it outside of our application.  If you run this app on chrome 65 you will see a corrupted image but open in 64 or firefox and you will see some text instead.  In js/app.js there is a comment that can trigger the behaviour as the corruption is only seen when reuploading a texture a second time to the same texture bank.
webgl_testcase_chrome65.zip
61.7 KB Download

Comment 2 by zmo@chromium.org, Feb 14 2018

Cc: ligim...@chromium.org
Labels: -Pri-2 M-65 ReleaseBlock-Beta Security_Impact-Beta Pri-1
Status: Available (was: Unconfirmed)
I can confirm this is a regression from M64 -> M65, but it's fixed on latest Canary (66.0.3347.0).


Comment 3 by zmo@chromium.org, Feb 14 2018

Cc: kbr@chromium.org jdarpinian@chromium.org kainino@chromium.org
This looks really bad! Ligi, can your team help bisecting?

We need two bisecting:
1) from M64->M65, where this regressed
2) from M65 (Beta) to M66 (Canary), where this was fixed

To reproduce,
1) download the zip file in #1, unzip into a local folder
2) in terminal, go to that folder, run python -m SimpleHTTPServer 8000
3) Open Chrome, goto localhost:8000, if we see clear texts, pass; otherwise, fail.

Comment 4 by zmo@chromium.org, Feb 14 2018

Labels: -ReleaseBlock-Beta ReleaseBlock-Stable

Comment 5 by zmo@chromium.org, Feb 14 2018

Cc: gov...@chromium.org
govind@, FYI. Just received this bug and it could be a security concern. It's already fixed on ToT. We just need to identify the regression and the fix, and merge it to M65 before it hits stable.

Comment 6 by gov...@chromium.org, Feb 14 2018

Cc: awhalley@chromium.org
Thank you zmo@, pls try to identify the regression and the fix ASAP and request a merge to M65 so we can pick it up for next week beta release before stable promotion.

+  awhalley@, security TPM as FYI
Cc: krajshree@chromium.org ajha@chromium.org
Sure , we can get this bisected.

Adding respective folks.
Labels: Triaged-ET RegressedIn-65 Target-65 FoundIn-65 hasbisect OS-Linux OS-Windows
Owner: junov@chromium.org
Status: Assigned (was: Available)
Able to reproduce the issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #65.0.3325.51 but the same is not reproducible in the latest canary #66.0.3347.0.

Providing 2 bisect results for when it was regressed and other for where was the fix.

1.Bisect Information: (when it was regressed)
=====================
Good build: 65.0.3325.29
Bad Build : 65.0.3325.31

Change Log URL: 
1. https://chromium.googlesource.com/chromium/src/+log/65.0.3325.29..65.0.3325.31?pretty=fuller&n=10000
2. https://chromium.googlesource.com/chromium/src/+/50866a21df4db7106c54f5879033623fba195c66

From the above change log suspecting below change
Change-Id: I3bfcb4499b52e9dc1725d67354ec5f62a861e7fb
Reviewed-on: https://chromium-review.googlesource.com/892082

2.Reverse Bisect Information: (where was the fix)
=====================
Good build: 65.0.3325.63
Bad Build : 65.0.3325.61

Change Log URL: 
1. https://chromium.googlesource.com/chromium/src/+log/65.0.3325.61..65.0.3325.63?pretty=fuller&n=10000
2. https://chromium.googlesource.com/chromium/src/+/245255909f0000029456f338047eebd2eb289deb

From the above change log suspecting below change
Change-Id: I2daa1096422a5a8fe1168b4bce495f48e10b37fb
Reviewed-on: https://chromium-review.googlesource.com/911608

junov@ - Could you please check and merge the fix to M-65 if it is a valid candidate.

Thanks...!!
Labels: -ReleaseBlock-Stable -M-65
It seems the issue has been fixed on latest beta #65.0.3325.73. Hence, removing M-65 and RBS label.

Comment 10 by junov@chromium.org, Feb 21 2018

Mergedinto: 805605
Status: Duplicate (was: Assigned)
Closing since this is no longer reproducible in latest beta or in Canary.

Seems to be the same root cause as issue 805605

Sign in to add a comment