Issue 2357 in v8: Uint8Array codegen errors with Chrome 22/Linux/x64

[codesite...@google.com]

Status: New
Owner: ----

New issue 2357 by paul.hol...@gmail.com: Uint8Array codegen errors with
Chrome 22/Linux/x64
http://code.google.com/p/v8/issues/detail?id=2357

One of the users of my emulator reported that it seemed to stop working as
Chrome 22 was released.

https://github.com/hulkholden/n64js/issues/3

The attached test.html reproduces the bug with Ubunutu 12.04/64-bit and
Chrome 22.0.1229.79. The bug does not seem to occur with Chrome 22 in
OSX/64bit or Ubuntu/32-bit.

I hesitated about raising this issue as it appears that the the bug is
fixed in Chrome 23+. But I'm unsure how long the Chrome release cycles are,
and perhaps this is significant enough to warrant hotfixing. Or perhaps
not :)

Anyway, the bug seems to be that after a number of iterations, the
following code seems to be optimised incorrectly.

return ((this.u8[offset] << 24) | (this.u8[offset+1] << 16) |
(this.u8[offset+2] << 8) | this.u8[offset+3])>>>0;

this.u8 is a Uint8Array. The bug seems to manifest with the top byte of the
result being thrown away (it comes through as 0). What's weird is that if I
change the value that's written to the array from 0xaaaaaaaa to 0x0aaaaaaa,
the bug appears to happen less frequently (about 25% of the time, vs 100%
of the time when 0xaaaaaaaa is used).

As I mentioned above, the bug does seem to be fixed (I tested using the
latest version of d8 on Ubuntu/64 and the test passed), but I'm just
raising in case someone thinks it's worth pushing a fix out to Chrome
stable.

Thanks,
Paul

Attachments:
test.html 2.2 KB

[codesite...@google.com]

Updates:
Status: Duplicate
Owner: verwa...@chromium.org
Mergedinto: chromium:142218

Comment #1 on issue 2357 by jkum...@chromium.org: Uint8Array codegen

errors with Chrome 22/Linux/x64
http://code.google.com/p/v8/issues/detail?id=2357

Yes, this is indeed fixed by r12362. Looks like we planned to back-merge
that :-)

Temporary workaround: Use simulated memory addresses that fit into a 31 bit
signed (30 bit unsigned) integer, i.e. 0 <= x <= 0x3fffffff.

[codesite...@google.com]

Comment #2 on issue 2357 by paul.hol...@gmail.com: Uint8Array codegen

errors with Chrome 22/Linux/x64
http://code.google.com/p/v8/issues/detail?id=2357

That's great - thanks for the update and apologies for the dupe.

In my case I have little control over the range of the values that are
used, but I'm happy to wait for the fix to roll around.