wasm/misc: getInt64 won't work in JavaScript #29786

xtuc · 2019-01-17T13:46:37Z

What version of Go are you using (`go version`)?

$ go version
go version go1.11.4 linux/amd64

Does this issue reproduce with the latest release?

The file on master has the same issue -

go/misc/wasm/wasm_exec.js

Lines 104 to 108 in 006a5e7

    
           const getInt64 = (addr) => { 
        
           	const low = mem().getUint32(addr + 0, true); 
        
           	const high = mem().getInt32(addr + 4, true); 
        
           	return low + high * 4294967296; 
        
           }

.

What operating system and processor architecture are you using (`go env`)?

Not relevant.

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/sven/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/sven/go"
GOPROXY=""
GORACE=""
GOROOT="/opt/go"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build772238647=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm working on https://github.com/wasm-tool/golang and ran into the issue when trying to bundle the following code:

package main

import "log"

func main() {
	log.Println("Called main!")
}

func foo() {
	log.Println("Called foo!")
}

What did you expect to see?

Wasm loading successully.

What did you see instead?

Uncaught (in promise) RangeError: Invalid typed array length: 1547732327792813600
    at typedArrayConstructByArrayBuffer (<anonymous>)
    at new Uint8Array (:8080/native)
    at loadSlice (wasm-loader.js?e1ab:267)
    at Object.runtime.getRandomData (wasm-loader.js?e1ab:344)
    at runtime.getRandomData (bundle.js:80)
    at :8080/wasm-function[892]:7
    at :8080/wasm-function[97]:118
    at :8080/wasm-function[480]:573
    at :8080/wasm-function[826]:165
    at :8080/wasm-function[873]:71
loadSlice @ wasm-loader.js?e1ab:267
runtime.getRandomData @ wasm-loader.js?e1ab:344
runtime.getRandomData @ bundle.js:80
<WASM UNNAMED> @ wasm-0099e9e2-892:4
<WASM UNNAMED> @ wasm-0099e9e2-97:53
<WASM UNNAMED> @ wasm-0099e9e2-480:248
<WASM UNNAMED> @ wasm-0099e9e2-826:65
<WASM UNNAMED> @ wasm-0099e9e2-873:37
run @ wasm-loader.js?e1ab:497
(anonymous) @ test.go?aa27:555
(anonymous) @ test.go:562
./src/test.go @ 1.bundle.js:67
__webpack_require__ @ bundle.js:132
Promise.then (async)
(anonymous) @ index.js?b635:1
./src/index.js @ bundle.js:311
__webpack_require__ @ bundle.js:132
(anonymous) @ bundle.js:299
(anonymous) @ bundle.js:302

Note that the error is not really relevant, the issue is that you cannot represent the full range of a 64 integrer is JavaScript (because it uses 64 bits floats as numbers).

The text was updated successfully, but these errors were encountered:

neelance · 2019-01-17T22:55:16Z

I can not reproduce this issue. The code

package main

import "log"

func main() {
	log.Println("Called main!")
}

func foo() {
	log.Println("Called foo!")
}

works fine for me.

Yes, it is known that getInt64 only returns a precision of 53 bits. I don't see how this is related to your crash. Please elaborate.

agnivade · 2019-01-18T04:07:57Z

OP is writing a webpack loader for Go. @xtuc - Could you please mention the entire steps for bundling the file through your loader and checking it in the browser ?

xtuc · 2019-01-18T10:21:05Z

I mentioned the the Webpack loader for context, but it's not relevant.

The issue is that passing an out-of-range Integer throws in JavaScript. For example the crash described here does something like:

const b = new ArrayBuffer(254);
const ptr = 2 ** 55;
const len = ptr + 4;
new Uint8Array(b, ptr, len);

Throws with Invalid typed array length: 36028797018963970.

I can reproduce it using the example in the repo https://github.com/wasm-tool/golang/tree/master/example.

That said, I'm wondering why I'm having such high addresses. Please let me know if I can provide more informations/tests.

neelance · 2019-01-18T10:58:19Z

Please provide a test that can reproduce the issue with env GOOS=js GOARCH=wasm go run test.go. If this is not possible, then the issue is not with the Go compiler/runtime itself.

I took a quick look at your code and my best guess is that getInt64 is for some reason not getting the same memory instance as the current WebAssembly instance is using and thus is reading bad values.

xtuc · 2019-01-18T11:10:21Z

I pretty sure I won't be able to reproduce the issue using the Go compiler itself and my example (Go run returns fork/exec /tmp/go-build105899162/b001/exe/test: exec format error my setup might be wrong).

However, the issue could theoretically occur in real world, if a program has adresses > 2**53. I agree that my bug might be caused by the Webpack loader itself.

Note that I opened the issue because of the potential usage of invalid numbers in JavaScript.

Edit: while you are taking a look at the loader; it's more or less a hack to use the wasm_exec.js in Webpack and its plugin system. It would be great if we had a better way to do it and I would be happy to discuss about it further.

neelance · 2019-01-18T11:17:36Z

2**53 is 8 PiB. Currently WebAssembly uses a continuous linear memory starting at address zero. So this is unlikely an issue.

xtuc · 2019-01-18T11:23:41Z

Yes, that's a good point. It's even unrepresentable in Wasm currently.

Ok, let's close this for now.

xtuc mentioned this issue Jan 17, 2019

Golang has WebAssembly support now, version 1.11 added wasm support wasm-tool/golang#1

Open

bradfitz assigned neelance Jan 17, 2019

bradfitz added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 17, 2019

bradfitz added this to the Go1.13 milestone Jan 17, 2019

dmitshur added the arch-wasm WebAssembly issues label Jan 17, 2019

xtuc closed this as completed Jan 18, 2019

golang locked and limited conversation to collaborators Jan 18, 2020

gopherbot added the FrozenDueToAge label Jan 18, 2020

rsc unassigned neelance Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wasm/misc: getInt64 won't work in JavaScript #29786

wasm/misc: getInt64 won't work in JavaScript #29786

xtuc commented Jan 17, 2019

neelance commented Jan 17, 2019

agnivade commented Jan 18, 2019

xtuc commented Jan 18, 2019 •

edited

neelance commented Jan 18, 2019

xtuc commented Jan 18, 2019 •

edited

neelance commented Jan 18, 2019

xtuc commented Jan 18, 2019

Navigation Menu

wasm/misc: getInt64 won't work in JavaScript #29786

wasm/misc: getInt64 won't work in JavaScript #29786

Comments

xtuc commented Jan 17, 2019

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

neelance commented Jan 17, 2019

agnivade commented Jan 18, 2019

xtuc commented Jan 18, 2019 • edited

neelance commented Jan 18, 2019

xtuc commented Jan 18, 2019 • edited

neelance commented Jan 18, 2019

xtuc commented Jan 18, 2019

What version of Go are you using (`go version`)?

What operating system and processor architecture are you using (`go env`)?

xtuc commented Jan 18, 2019 •

edited

xtuc commented Jan 18, 2019 •

edited