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

Issue 719866 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug


Participants' hotlists:
Hotlist-AsmJsParser


Sign in to add a comment

asm.js code generation regression in Chrome Canary (60.0.3094.0)

Project Member Reported by flo...@gmail.com, May 9 2017

Issue description

Chrome Version: 60.0.3094.0 (Official Build) canary (64-bit)
OS: Mac OS X

What steps will reproduce the problem?
(1) in Chrome Canary, go here: http://floooh.github.io/oryol/asmjs/DebugText.html,
note how the screen is mostly grey, and there are colored pixels dropping down in the upper right 
(2) in Chrome Stable, or any other browser, do the same, and note how the characters fill the whole screen

This happens for emscripten-compiled code with -O3 and -O2, but not -O0 or -O1. It is not an emscripten regression, it also happens with older emscripten SDKs.

It is not a WebGL- or shader-problem, instead there seems to be an asm.js code-generation error.

The problem happens with this C++ code:

        const float w = 8.0f / Gfx::PassAttrs().FramebufferWidth;
        const float h = 8.0f / Gfx::PassAttrs().FramebufferHeight;
        vsParams.GlyphSize = glm::vec2(w * 2.0f, h * 2.0f) * this->textScale;

The FramebufferWidth/FramebufferHeight are integers, everything else are floats. The resulting GlyphSize is too small by a factor or 8 or 16, re-arranging the expression slightly makes it work, for instance:

        const float w = (16.0f * this->textScale.x) / Gfx::PassAttrs().FramebufferWidth;
        const float h = (16.0f * this->textScale.y) / Gfx::PassAttrs().FramebufferHeight;
        vsParams.GlyphSize = glm::vec2(w, h);

The problem only happens in asm.js, not in WebAssembly.


 

Comment 1 by flo...@gmail.com, May 9 2017

PS: the problem happens in Canary *60.0.3094.0* on OSX.

On a Windows7 machine, I have Canary version 60.0.3091.0 (slightly older) this looks correct. Looks like the problem appeared in 3092, 3093 or 3094 (or is OSX-specific).
Cc: bradnelson@chromium.org
Components: Blink>JavaScript>WebAssembly
@brad, is asm->wasm on by default in M60?

Comment 3 by flo...@gmail.com, May 9 2017

A few more affected demos, note how the UI rendering is broken (but in a very consistent way):

- http://floooh.github.io/oryol-samples/asmjs/ImGuiDemo.html
- http://floooh.github.io/oryol-samples/asmjs/DrawCallExplorer.html
- http://floooh.github.io/oryol-samples/asmjs/SoloudMOD.html
- http://floooh.github.io/oryol-samples/asmjs/SoloudTedSid.html
- http://floooh.github.io/oryol-samples/asmjs/SoundTest.html

The only demo which uses Dear Imgui without rounded corners looks mostly alright (only the vertical scroll bar is broken when opening the Camera or Light settings):

- http://floooh.github.io/oryol-samples/asmjs/MeshViewer.html

Comment 4 by flo...@gmail.com, May 9 2017

...Canary 60.0.3094.0 64-bit on a Win10 machine does not show the problem (same version as the OSX machine that has the problem). Strange.
Owner: mstarzinger@chromium.org
Status: Assigned (was: Untriaged)

Comment 6 by flo...@gmail.com, May 16 2017

Hi, any news on this? Does the problem reproduce on your side? Thanks :)

Comment 7 by flo...@gmail.com, May 29 2017

Found another emscripten demo page which is affected by this problem:

The skeletal animation blending samples linked by this page are all broken (all 3D rendering is just a single vertical line): http://guillaumeblanc.github.io/ozz-animation/samples/

For instance:

http://guillaumeblanc.github.io/ozz-animation/samples/playback/

Comment 8 by juj...@gmail.com, May 30 2017

I am able to reproduce. On a MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) with macOS Sierra 10.12.3,

works on Google Chrome Version 60.0.3108.0 (Official Build) canary (64-bit), but
fails on Google Chrome Version 61.0.3115.0 (Official Build) canary (64-bit).

Comment 9 by flo...@gmail.com, Jun 1 2017

The bug now also occurs on Windows, so it doesn't seem to be Mac specific:

Chrome: Version 61.0.3116.0 (Offizieller Build) canary (64-Bit)

Windows 7 Enterprise 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.150202-1526)



Labels: -Pri-3 Pri-2
Status: Started (was: Assigned)
Thanks for the report! Started investigating. I can reproduce this with asm.js validation enabled (also reproduces on Linux). @floooh, can you confirm that you have the asm.js to WASM translation flag[1] enabled?

[1] chrome://flags/#enable-asm-webassembly
The plot is thickening. The following is a somewhat reduced repro ...

----

function Module(stdlib, foreign, buffer) {
  "use asm";
  var i32 = new stdlib.Int32Array(buffer);
  var f32 = new stdlib.Float32Array(buffer);
  function f(a) {
    a = a | 0;
    var r = 0.0;
    r = +f32[a + 4 >> 2] * (8.0 / +(i32[a + 8 >> 2] | 0) * 2.0);
    return +r;
  }
  return { f:f }
}
var b = new ArrayBuffer(1024);
var m = Module(this, {}, b);

var i32 = new Int32Array(b);
var f32 = new Float32Array(b);
i32[8 >> 2] = 100;
f32[4 >> 2] = 1000.0;

print("Result:", m.f(0));

----

Result without asm.js validation:
$ ./out/x64.debug/d8 test/mjsunit/foo.js --validate-asm
Result: 40

Result with asm.js validation enabled:
$ ./out/x64.debug/d8 test/mjsunit/foo.js 
Result: 160

Project Member

Comment 12 by bugdroid1@chromium.org, Jun 1 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/15691758b300ec1edcf505b2c28ee118356b45ff

commit 15691758b300ec1edcf505b2c28ee118356b45ff
Author: Michael Starzinger <mstarzinger@chromium.org>
Date: Thu Jun 01 13:03:03 2017

[asm.js] Fix associativity of multiplicative expressions.

R=clemensh@chromium.org
TEST=mjsunit/asm/regress-719866
BUG= chromium:719866 

Change-Id: I6cc9f222769aa036275654286c9c6271ef2d1334
Reviewed-on: https://chromium-review.googlesource.com/520945
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45660}
[modify] https://crrev.com/15691758b300ec1edcf505b2c28ee118356b45ff/src/asmjs/asm-parser.cc
[add] https://crrev.com/15691758b300ec1edcf505b2c28ee118356b45ff/test/mjsunit/asm/regress-719866.js

Status: Fixed (was: Started)

Comment 14 by flo...@gmail.com, Jun 1 2017

@mstarzinger: Already fixed? That was quick, nice :)

About your question: on Canary (where the bug happens) #enable-asm-webassembly is "Enabled", on the Chrome (where the bug doesn't happen) the flag is set to "Default".

When setting the flag to "Default" on Canary the problem disappears.
Re #14: Thanks. This is consistent with my observations. The bug (and hence my fix) only applies to the asm.js to WebAssembly translation that is controlled by the flag in question. Turning on the flag should trigger the bug, turning it off should make it go away. Note that we also have a field trial running on the Canary channel that turns on the feature for some installations.

Also I just checked and the fix has made it into the 61.0.3118.0 Canary. If you see the bug (or any other bug specific to asm.js modules) persisting beyond that version, please don't hesitate to file another issue and CC me on it. All feedback about asm.js in the wild is very much appreciated. Thanks!

Comment 16 by flo...@gmail.com, Jun 2 2017

I just got the update to 61.0.3118.0 and the fix is included. Thanks a lot!

Sign in to add a comment