Looks like an incorrect memory address being generated. Are you able to post a code sample that triggers this?

/cc @neelance

Unfortunately, I can't post a code sample here. But there is another weird behavior:

• Here has there functions code with golang build into wasm
• After read those two big files, WebSite memory usage about 2.1 GB
• After read those two files, this error occurs when calling function A. (memory not change very much)
• After read those two files, this time I call function B first, no error; Then I call function A, no error either. (memory not change very much too)

Finally, If those files are small file under 20MB, this error will not occur.

Sorry, I have no idea what is causing this. I would need to be able to reproduce it to investigate.

Sorry, I have no idea what is causing this. I would need to be able to reproduce it to investigate.

Here is a sample code, occur this error. https://github.com/lianghx-319/golang-issue-40923

Maybe deploy a online preview soon.

Hi, random passer-by here! I found this issue last week because I was getting the same error message. This week, I tried updating to Go 1.15 and rebuilding my code, and this error message seems to have gone away. I haven't attempted to track it down any further.

Sorry, I have no idea what is causing this. I would need to be able to reproduce it to investigate.

Here is a sample code, occur this error. https://github.com/lianghx-319/golang-issue-40923

Maybe deploy a online preview soon.

Hello, @agnivade, I am colleague of lianghx-319 . Could take a look at this reproduce repo?

It seem that this bug is caused by high memory use. We have optimized memory use of golang wasm in our internal project code which reduce the whole tab memory footprint to about 1.3G with the same file, then this error message gone away.

The error we are specifically running into seems this one -
https://groups.google.com/a/chromium.org/g/chromium-dev/c/IKZvzuBP9QE
2GB memory limit per renderer (i.e. per tab)

Without looking too much into it, and just looking at the symptoms, apart from the Chrome memory limit, it might also be possible that you are hitting the limits of the wasm linear memory. Currently, wasm linear memory supports only 32 bit addresses, which limits its total size to 4GiB. So anything above that will not work (and is likely causing an overflow for a 32 bit number). I think we just need to handle this case better and throw a nice error message.

Digging into the reproducer should verify if this is indeed the case. What is the behavior in other browsers?

In any case, it might help if you could try with 1.15. That has a number of optimizations which might generally help you to reduce memory usage.

Without looking too much into it, and just looking at the symptoms, apart from the Chrome memory limit, it might also be possible that you are hitting the limits of the wasm linear memory. Currently, wasm linear memory supports only 32 bit addresses, which limits its total size to 4GiB. So anything above that will not work (and is likely causing an overflow for a 32 bit number). I think we just need to handle this case better and throw a nice error message.

Digging into the reproducer should verify if this is indeed the case. What is the behavior in other browsers?

In any case, it might help if you could try with 1.15. That has a number of optimizations which might generally help you to reduce memory usage.

The overall memory our website use is about 2GiB, so it not likely that 32 bits addr will overflow.

Change https://golang.org/cl/261358 mentions this issue: misc/wasm: make sure sp is unsigned