WASM crashes in some code paths (null function or function signature mismatch)

[adamziel]

I've ran into this error in PHP 7.4, likely related to the recent removal of -s EMULATE_FUNCTION_POINTER_CASTS

RuntimeError: null function or function signature mismatch
    at php.wasm.read_markers (wasm://wasm/php.wasm-06f29a42:wasm-function[13283]:0x8e7c94)
    at php.wasm.consume_markers (wasm://wasm/php.wasm-06f29a42:wasm-function[13273]:0x8e69b6)
    at php.wasm.jpeg_consume_input (wasm://wasm/php.wasm-06f29a42:wasm-function[13247]:0x8e2b44)
    at php.wasm.jpeg_read_header (wasm://wasm/php.wasm-06f29a42:wasm-function[13246]:0x8e2aba)
    at php.wasm.gdImageCreateFromJpegCtxEx (wasm://wasm/php.wasm-06f29a42:wasm-function[1473]:0x3cee1d)
    at php.wasm.zif_imagecreatefromstring (wasm://wasm/php.wasm-06f29a42:wasm-function[1291]:0x3b875b)
    at php.wasm.ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (wasm://wasm/php.wasm-06f29a42:wasm-function[8231]:0x653cb0)
    at php.wasm.execute_ex (wasm://wasm/php.wasm-06f29a42:wasm-function[7468]:0x60bfff)
    at php.wasm.zend_execute (wasm://wasm/php.wasm-06f29a42:wasm-function[7470]:0x60c205)
    at php.wasm.zend_execute_scripts (wasm://wasm/php.wasm-06f29a42:wasm-function[6612]:0x5c6c80)

Let's use this issue to document all the related crashes.

[adamziel]

Unrelated but also needs a fix:

RuntimeError: memory access out of bounds
    at php.wasm.std::__2::basic_ostream<char, std::__2::char_traits<char>>::flush() (wasm://wasm/php.wasm-073c60e6:wasm-function[37251]:0xef5e52)
    at php.wasm.std::__2::DoIOSInit::~DoIOSInit() (wasm://wasm/php.wasm-073c60e6:wasm-function[37604]:0xf02b29)
    at php.wasm.__cxx_global_array_dtor.1 (wasm://wasm/php.wasm-073c60e6:wasm-function[37606]:0xf02ba0)
    at php.wasm.__funcs_on_exit (wasm://wasm/php.wasm-073c60e6:wasm-function[34854]:0xe97f70)
    at ret.<computed> (file:///Users/cloudnik/www/Automattic/core/plugins/playground/packages/php-wasm/node/jspi/php_8_0.js:18190:14)
    at runtime.wasmExports.<computed> (/Users/cloudnik/www/Automattic/core/plugins/playground/packages/php-wasm/universal/src/lib/wasm-error-reporting.ts:59:13)
    at ___funcs_on_exit (file:///Users/cloudnik/www/Automattic/core/plugins/playground/packages/php-wasm/node/jspi/php_8_0.js:34097:54)
    at exitRuntime (file:///Users/cloudnik/www/Automattic/core/plugins/playground/packages/php-wasm/node/jspi/php_8_0.js:305:3)
    at exitJS (file:///Users/cloudnik/www/Automattic/core/plugins/playground/packages/php-wasm/node/jspi/php_8_0.js:8623:4)
    at php.wasm.main (wasm://wasm/php.wasm-073c60e6:wasm-function[9292]:0x6c1456) {
  cause: Error
      at Asyncify.handleSleep (file:///Users/cloudnik/www/Automattic/core/plugins/playground/packages/php-wasm/node/jspi/php_8_0.js:34262:41)
      at _emscripten_sleep (file:///Users/cloudnik/www/Automattic/core/plugins/playground/packages/php-wasm/node/jspi/php_8_0.js:16705:19)
      at php.wasm.__wrap_select (wasm://wasm/php.wasm-073c60e6:wasm-function[8802]:0x691240)
      at php.wasm.Curl_socket_check (wasm://wasm/php.wasm-073c60e6:wasm-function[21472]:0xb185f9)
      at php.wasm.curl_multi_perform (wasm://wasm/php.wasm-073c60e6:wasm-function[21437]:0xb14551)
      at php.wasm.zif_curl_multi_exec (wasm://wasm/php.wasm-073c60e6:wasm-function[897]:0x394b7b)
      at php.wasm.ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_USED_HANDLER (wasm://wasm/php.wasm-073c60e6:wasm-function[7982]:0x6509eb)
      at php.wasm.execute_ex (wasm://wasm/php.wasm-073c60e6:wasm-function[7208]:0x605419)
      at php.wasm.zend_execute (wasm://wasm/php.wasm-073c60e6:wasm-function[7210]:0x605684)
      at php.wasm.zend_execute_scripts (wasm://wasm/php.wasm-073c60e6:wasm-function[6745]:0x5e565a)
}

[adamziel]

The cxx_global_array_dtor issue might potentially be resolved by setting -sEXIT_RUNTIME=0. It never crashes with this patch:

-	var ___funcs_on_exit = () => (___funcs_on_exit = () => { })();
+	var ___funcs_on_exit = () => (___funcs_on_exit = wasmExports['__funcs_on_exit'])();

In the browser, we probably don't have to worry about cleaning up the resources because we're about to destroy the heap. In Node.js, I wonder if we'd risk leaving any dangling file locks 🤔 Although we control the JS kernel so we should free them in try { } finally { } anyway.