Nice! Glad you found that.
On Mon, Sep 14, 2020 at 6:19 PM Александр Гурьянов
wrote:
> Okay) This is very stupid, I created test case and was so close to
> create issue, but I found a reason.
> It's because I have this:
> -s EXTRA_EXPORTED_RUNTIME_METHODS=\"['getMemory', ...
>
Okay) This is very stupid, I created test case and was so close to
create issue, but I found a reason.
It's because I have this:
-s EXTRA_EXPORTED_RUNTIME_METHODS=\"['getMemory', ...
Actually it's never used and when I removed it all tests were passed.
Thanks!
пн, 14 сент. 2020 г. в
You can add this:
function getMemory() {
abort(new Error().stack);
}
and then when it is called it will halt with a stack trace. That can help
figure out what is calling it. (Make sure to build with --profiling so the
stack trace is clear.)
On Mon, Sep 14, 2020 at 7:53 AM 'Sam Clegg' via
Can you give steps to reproduce? Perhaps you can open an issue in the bug
tracker?
Can you tell which JS function is referencing `getMemory`?It should
be removed from the codebase (except if `-s MAIN_MODULE` is used).
cheers,
sam
On Sun, Sep 13, 2020 at 8:24 PM Александр Гурьянов
Sorry I don't understand what I should do. This error happens on a
regular codebase without something special (just libzip and extraction
code). I use emsdk, emcmake, cmake and make to compile it. I don't
call getMemory or dynamicAlloc from my side, I mean how can I call
them before instantiation
These functions were removed since we managed to remove all our allocations
that occurred before startup.
This is/was an important thing for us to do as it allows wasm-ld (the
static linker) to fully determine memory layout and specifically heap
location without the need for post-link
