Memory issues on iOS Safari? about quickjs-emscripten HOT 7 CLOSED

Hi @carlosdp, thanks for the bug report. I haven't seen these kinds of issues on iOS, but I haven't used Scope there much myself.

My test page here https://jake.tl/projects/quickjs-emscripten seems to work okay on iOS, does using this thingy throw errors for you? On every keystroke, a runtime is created and the script is eval'd. But, there's no exercising of object creation or the Scope APIs.

from quickjs-emscripten.

I created a replication here: https://github.com/carlosdp/quickjs-memory-leak . This one actually happens on Chrome too. We're using evalCode and not creating a VM explicitly, so we aren't creating any external objects, yet there's the memory assertion error.

Would greatly appreciate any help figuring this out!

from quickjs-emscripten.

I tried the repro today, but didn't hit any issues. Then, I noticed that your package.json uses a relative path for quickjs-emscripten. I changed to use 0.11.0 from NPM (carlosdp/quickjs-memory-leak#1) and then I encountered a RuntimeError on my iPhone.

Tested on:

• MacBook Pro (15-inch, 2018) / macOS 11.2.3 / Chrome 89.0.4389.128 (Official Build) (x86_64).
  • "undefined" return value.
• MacBook Pro (15-inch, 2018) / macOS 11.2.3 / Safari 14.0.3 (16610.4.3.1.7)
  • "undefined" return value.
• iPhone 12 Pro Max / iOS 14.4.2
  • [RuntimeError: abort(Assertion failed: list_empty(&rt->gc_obj_list), at: quickjs/quickjs.c,1964,JS_FreeRuntime). Build with -s ASSERTIONS=1 for more info. (evaluating 'new WebAssembly.RuntimeError("abort(" + b + "). Build with -s ASSERTIONS=1 for more info.")')]

from quickjs-emscripten.

Yea, sorry about the relative path =P I tried to dig into why this is happening. I suspect potentially it has to do with how the heap is being allocated for the code string? It has to be an external reference, right? And in this example, the only external reference really is the code itself.

Running the same code in native-compiled QuickJS runs without issue, so there's that

from quickjs-emscripten.

Ok, there's two issues here:

1. Scope.withScope is obscuring the issue. The block is throwing an error, then the scope tries to dispose the lifetimes it manages, and that throws an error that replaces the block error. So, it looks like there's a leak, but the actual buginess is inside the block.
2. Once that is fixed (in #36) I see the "out of bound" access error.

I googled this one a bit and found some very disturbing issue reports online about iOS WebAssembly problems. I hope we have a programming mistake in the repo, but because things work in other browsers, I'm somewhat inclined to believe this is in part an iOS issue.

• emscripten-core/emscripten#6042
• emscripten-core/emscripten#8121 (comment)
• https://bugs.webkit.org/show_bug.cgi?id=181723

from quickjs-emscripten.

Interestingly, this issue doesn't occur for me on first load of the page on my iPhone if the tab gets "unloaded" after a couple hours idle. And the frequency of the issue is way down even when hammering the refresh button with newer QuickJS #37

from quickjs-emscripten.

Yea, I looked at those Safari issues again, it looks like it has a lot to do with binary size potentially. Tried compiling with -Oz to optimize for size, and the error went away.

from quickjs-emscripten.