Asyncify Crash in the Woocommerce onboarding flow

[adamziel]

WP 6.4, PHP 8.0, networking enabled, no extra extensions. After installing the Woocommerce plugin, going through the Woo onboarding flow halts at one moment with a bunch of Asyncify errors. Let's identify where they come from and add the required functions to the ASYNCIFY_ALLOWLIST in the PHP build Dockerfile as well as thephp-asyncify.spec.ts unit tests

Here's a few ideas that would be good to test and Asyncify-allowlist regardless:

• Generators
• Stream wrappers
• Shutdown handlers

To get nice stacktraces in the web version of PHP, it needs to be rebuilt with -O0 -g2 emcc flags here (hardcoding them for testing is fine):

wordpress-playground/packages/php-wasm/compile/php/Dockerfile

Line 805 in c1e7433

emcc $OPTIMIZATION_FLAGS \

[bgrgicak]

Test url https://playground.wordpress.net/?php=8.0&wp=6.4&storage=none&networking=yes&plugin=woocommerce&url=/wp-admin/

[bgrgicak]

I was able to recreate the issue locally. But after running npm run recompile:php:web:light:8.0 I can't recreate it anymore but not sure why.

[adamziel]

Weird @bgrgicak! Is there any chance it only happens in the kitchen sink bundle or with networking enabled? It could also be slightly non-deterministic, I remember successfully configuring woo in the past.

[bgrgicak]

I'm not sure why is this happening, but I had the same experience with PHP 8.1. I was able to recreate it until I rebuilt PHP. Then it stopped.

It also looks like these errors aren't producing crashes, Woo keeps running after the error, but it's slow.

@adamziel would you have some time to pair on this?

[adamziel]

@adamziel would you have some time to pair on this?

Sure, let's pair on Monday.

[adamziel]

I reproduced this issue with a PHP build that retains the function names, here's the stack trace I got:

base-php.ts:603 RuntimeError: null function or function signature mismatch
    at zend_objects_store_del (0164ced2:0xe801)
    at autoload_func_info_destroy (0164ced2:0x15262d)
    at autoload_func_info_zval_dtor (0164ced2:0x38a060)
    at zend_hash_destroy (0164ced2:0x897d)
    at zm_deactivate_spl (0164ced2:0x283eab)
    at dynCall_iii (0164ced2:0x3835d3)
    at ret.<computed> (php_8_0.js?t=1710169250590:6333:24)
    at runtime.asm.<computed> (wasm-error-reporting.ts:45:13)
    at invoke_iii (php_8_0.js?t=1710169250590:7125:10)
    at zend_deactivate_modules (0164ced2:0x314b72)
errorListener @ base-php.ts:603
runtime.asm.<computed> @ wasm-error-reporting.ts:60
invoke_iii @ php_8_0.js?t=1710169250590:7125
$zend_deactivate_modules @ 0164ced2:0x314b72
$dynCall_v @ 0164ced2:0x382f2a
ret.<computed> @ php_8_0.js?t=1710169250590:6333
runtime.asm.<computed> @ wasm-error-reporting.ts:45
invoke_v @ php_8_0.js?t=1710169250590:7224
$wasm_sapi_request_shutdown @ 0164ced2:0x3175f3
$dynCall_v @ 0164ced2:0x382f2a
ret.<computed> @ php_8_0.js?t=1710169250590:6333
runtime.asm.<computed> @ wasm-error-reporting.ts:45
invoke_v @ php_8_0.js?t=1710169250590:7224
$wasm_sapi_handle_request @ 0164ced2:0x31bfd2
ret.<computed> @ php_8_0.js?t=1710169250590:6333
runtime.asm.<computed> @ wasm-error-reporting.ts:45
ccall @ php_8_0.js?t=1710169250590:6524
exitCode @ base-php.ts:613
#handleRequest @ base-php.ts:600
run @ base-php.ts:278
error (async)
addEventListener @ wasm-error-reporting.ts:13
exitCode @ base-php.ts:609
#handleRequest @ base-php.ts:600
run @ base-php.ts:278
await in run (async)
#dispatchToPHP @ php-request-handler.ts:243
await in #dispatchToPHP (async)
request @ php-request-handler.ts:119
request @ php-browser.ts:61
request @ base-php.ts:234
request @ web-php-endpoint.ts:99
(anonymous) @ api.ts:169
callback @ comlink.ts:329