Missing methods on INCOMING_MODULE_JS_API, like onMalloc

[ivancuric]

Please include the following in your bug report:

Version of emscripten/emsdk:
3.1.32

CMAKE link options:

        "SHELL:-s MODULARIZE=1"
        "SHELL:-s EXPORT_NAME=${MODULE_NAME}"
        "SHELL:-s ENVIRONMENT=web,worker"
        "SHELL:-s FETCH=1"
        "SHELL:-s DYNAMIC_EXECUTION=0"
        "SHELL:-s STRICT=0"
        "SHELL:-s IMPORTED_MEMORY=1"
        "SHELL:-s --minify 0"
        "SHELL:-s --closure 0"
        "SHELL:-s INCOMING_MODULE_JS_API=onMalloc" # same with or without

Looking at the output .js files, or logging the Module object, there are tons of things missing from https://github.com/emscripten-core/emscripten/blob/main/src/settings.js#L951C5-L965.

I'd especially need methods that are related to memory management. Is there any reason why they aren't included?

[sbc100]

I see onMalloc and onFree in the https://github.com/emscripten-core/emscripten/blob/main/src/settings.js#L951C5-L965.

What is the error that you are seeing exactly?

What are you trying to use onMalloc for by the way? It looks like its only used in library_tracing.js which is used when you pass --tracing or --memoryprofiler.. aer you using one of those?

[sbc100]

BTW, if you are using cmake you can avoid the SHELL: syntax I believe by removing the space between the -s and the setting name. e.g. -sMODULARIZE. Then you can pass -s settings as normal flags.

Also, I'm not sure how -s --minify 0 is working since --minify=0 and --closure=0 are not -s settings but normal compiler flags.

[ivancuric]

I have tried using --tracing or --memoryprofiler but there is no overlay present as I'm running the WASM on a web worker, nor can I understand how I can reach those methods.

When I log the Module object, these are the properties present, apart from those exposed by embind:

[
    "locateFile",
    "INITIAL_MEMORY",
    "wasmMemory",
    "ready",
    "expectedDataFileDownloads",
    "preRun",
    "onAbort",
    "FS_createPath",
    "FS_createDataFile",
    "FS_createPreloadedFile",
    "FS_unlink",
    "FS_createLazyFile",
    "FS_createDevice",
    "InternalError",
    "BindingError",
    "getInheritedInstanceCount",
    "getLiveInheritedInstances",
    "flushPendingDeletes",
    "setDelayFunction",
    "UnboundTypeError",
    "count_emval_handles",
    "get_first_emval",
    "emscripten_trace_configure",
    "emscripten_trace_configure_for_google_wtf",
    "emscripten_trace_enter_context",
    "emscripten_trace_exit_context",
    "emscripten_trace_log_message",
    "emscripten_trace_mark",
    "_fflush",
    "___getTypeName",
    "__embind_initialize_bindings",
    "dynCall_ji",
    "dynCall_jiji",
    "dynCall_viijii",
    "dynCall_iiiiij",
    "dynCall_iiiiijj",
    "dynCall_iiiiiijj",
    "__ZN2MB2NN28LinearDefragmentingAllocator10Allocation4nullE",
    "___heap_base",
    "___start_em_js",
    "___stop_em_js",
    "addRunDependency",
    "removeRunDependency",
    "dataFileDownloads",
    "asm",
    "HEAP8",
    "HEAP16",
    "HEAP32",
    "HEAPU8",
    "HEAPU16",
    "HEAPU32",
    "HEAPF32",
    "HEAPF64",
    "preloadResults",
    "calledRun",
    "stdin",
    "stdout",
    "stderr"
]

All of this might be way over my head, but what would be the correct way of debugging memory usage on a web worker?

[sbc100]

Regarding the exports on the module object, I would love to reduce those. I recently landed #21439 which removes the HEAPXX exports in -sSTRICT mode.

My first question is, are these exports causing any kind of runtime failure for you?

Secondly, I see _ZN2MB2NN28LinearDefragmentingAllocator10Allocation4nullE in there which is a C++ symbol (MB::NN::LinearDefragmentingAllocator::Allocation::null). Do you know how that symbol ends up being exported? Are there any other command line flags that might cause that?

[sbc100]

Regarding --memoryprofiler I believe that need to run on the main browser there. I don't think there is any support for profiling things running in workers.

[ivancuric]

My first question is, are these exports causing any kind of runtime failure for you?
No, not really. What I'm solving is an iOS Safari issue where it will randomly prevent wasm memory growth.

My question was more in line if I should expect all things in INCOMING_MODULE_JS_API to be available on the Module object, which it is in fact not. The list of exports was there just to demonstrate that it isn't.

Regarding --memoryprofiler I believe that need to run on the main browser there. I don't think there is any support for profiling things running in workers.

Would be extremely helpful if there was just an optional callback that would be exposed on the Module. For now I manually edit the updateMemoryViews function after every compilation. I was hoping there was something on INCOMING_MODULE_JS_API which I could hook into.

Do you know how that symbol ends up being exported?

Will check and get back to you.

[sbc100]

The INCOMING_MODULE_JS_API is a way to control what settings are allowed on the Module that you provide as input to emscripten. i.e. thing that you can override. For most things in that list the only time you would see it is if you supplied that on the Module object that you pass into emscripten (this is the argument to the constructor function in the case of -sMODULARIZE).

By adding or removing things from the last list you make emscripten more or less configurable. Setting it to the empty list give you the smallest output.. but then you have a less configurable module.