image/png: different decoding result on iOS Safari (Wasm)

[hajimehoshi]

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

$ go version
go version devel +b388d68 Thu Jun 13 03:58:18 2019 +0000 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hajimehoshi/Library/Caches/go-build"
GOENV="/Users/hajimehoshi/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/hajimehoshi/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/hajimehoshi/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/hajimehoshi/sdk/gotip/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ht/ky_bwgzs4bd5z1hh02k34x_h0000gn/T/go-build197596843=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Compile this program as Wasm and run it on iOS Safari

https://play.golang.org/p/4ez7BztzRZf

package main

import (
        "bytes"
        "image/color"
        "image/png"
)

var pngimg = []byte("\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00 \x00\x00\x00 \b\x02\x00\x00\x00\xfc\x18\xed\xa3\x00\x00\x00\tpHYs\x00\x00\v\x13\x00\x00\v\x13\x01\x00\x9a\x9c\x18\x00\x00\x00<IDATH\xc7\xedѱ\r\x000\b\x03A\xc8J\xec\xbf\x01\x9e\xc9̀\x944\xd1\u007fmt\x05\xd9ݱ\xa9\xaaV\xfb\x13\x8f\x03\x00\x00\x00\x00\xb8Q\xda^\x1dH\xe2\a\x00\x00\x00\x00\xff\x01\x03\xd79\b\xa0\u007fq\xb3\xbb\x00\x00\x00\x00IEND\xaeB`\x82")

func main() {
        img, err := png.Decode(bytes.NewReader(pngimg))
        if err != nil {
                panic(err)
        }
        println(img.At(16, 15).(color.RGBA).R, img.At(16, 15).(color.RGBA).A)
        println(img.At(16, 16).(color.RGBA).R, img.At(16, 16).(color.RGBA).A)
}

What did you expect to see?

On console:

255 255
204 255

What did you see instead?

204 255
255 255

or

0 255
255 255

Note

This works correctly on any other browsers than iOS Safari, including desktop Safari.

[hajimehoshi]

CC @neelance

[neelance]

This seems like a bad WebAssembly implementation on iOS Safari. Which version of Safari is it?

[hajimehoshi]

The iOS version is 12.3.1, which is the latest. Safari version should follow the iOS version.

[neelance]

I can not reproduce it, because I do not own an iPhone. It would be really helpful if someone could get more details about what is going on.

[hajimehoshi]

IIUC wasmWrite is called for println and something strange happened before println.

[agnivade]

I would like to understand if the issue is with println or with the values themselves. Is it possible to store the values to some variables and then use unsafe to get the memory addressees and jump to JS and print the wasm memory buffer at that pointer and check the values ?

[hajimehoshi]

I found this issue with WebGL (gl.texSubImage2d) by showing this image, so I believe this problem is with the value themselves.

[dmitshur]

I can reproduce the issue in iOS 12.4.1 at https://dmitri.shuralyov.com/temp/issue32635/.

The issue does not seem to reproduce in iOS 13.

Perhaps they've fixed it in iOS 13? Edit: It looks that way, see hajimehoshi/ebiten#631 (comment).

[hajimehoshi]

Now I got an iOS 13 device (iPod touch), and I found there is still something wrong...

e.g. https://ebiten.org/examples/animation.html

I have not created a minimum case yet.

EDIT: Sorry mine was iOS 12, not iOS 13. I'll retry this with iOS 13.

[hajimehoshi]

Yes, I have confirmed that this was fixed on iOS 13.1.3. Thank you!

[hajimehoshi]

Not related to this issue, but I found that Go/Wasm application (e.g. https://ebiten.org/examples/flappy.html) takes too much memory like 1.9GB and the tab is automatically reloaded soon on my iPod (7th generation, iOS 13.1.3).