Enhancement request for "RuntimeError: null function or function signature mismatch"

[John Dallman]

The codebase I'm porting to WebAssembly is mostly C, rather than C++, and parts of it are decades old. I'm having to clean up places where it gets clever with function calling. 

The error "RuntimeError: null function or function signature mismatch" would be more helpful if it told you the function signature used for making the call, as well as the correct signature for the function (in the traceback). Normally, it's easy to tell what signature was used for making the call, but sometimes it is not obvious.

I'm not sure if this would be an enhancement to Emscripten or Node? 

Thanks, 

John Dallman

[John Dallman]

Now I've realised my mistake, let's rephrase that:

The error "RuntimeError: null function or function signature mismatch" would be more helpful if it told you the function signature used for making the call, and the correct signature for the function. 

Normally, it's easy to tell what signature was used for making the call, but sometimes it is not obvious.

Thanks,

John

[Alon Zakai]

If you run in a browser debugger, you can get a stack trace of where it errors (by doing "pause on exceptions"). In that trace you can see the call, and the signature used there. Building with -gsource-map, you will get the source location of the error which is usually most convenient.

Seeing the signature of the called function is harder, but usually you can see the index in the table that is called, and look at the item at that index, as the table is normally filled once and then immutable (except in dynamic linking and other situations). For this it is helpful to look at the wasm itself, not the source code, so building *without* source maps, then pausing on the exception, is helpful.

I do agree it would be nice if the error were clearer without a debugger, though. I actually see that UBSan reports something here in native builds but not wasm, and filed a bug for it:

https://github.com/emscripten-core/emscripten/issues/26600

- Alon

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgmwrsOtPpQAc2-VEh%3DFTpey%3Do4_W7o0LD3gBtGaSR%2BxFg%40mail.gmail.com.

[John Dallman]

The library I'm porting to WebAssembly is backend code that really makes more sense as native code on a cloud server, and already runs there. However, there are customers who want WebAsm. Redesigning the test harness to work in a browser UI would be a huge task, so I'm doing all my testing in Node.js. I'm generating and using the symbol map to interpret tracebacks.

I've found that the emcc option -Werror=cast-function-type-strict finds lots of these errors at compile time, so I'm going to clean them up there first. Adding a note of that to https://emscripten.org/docs/porting/guidelines/function_pointer_issues.html would be helpful for future people with similar problems. 

Thanks, 

John

      

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR4T2WV%3DF6a3hh5tvt3RFtwXOLJwDYC0DTdqsWKhFWCvQ%40mail.gmail.com.

[Alon Zakai]

Good idea, we'll add mention of that flag here:

https://github.com/emscripten-core/emscripten/pull/26667

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgnyQLg%2BqMd994xnBUz%3D6ro_pzQo9QmpPYx3sRSi4KdZmg%40mail.gmail.com.