WooCommerce & Errors - TypeError: Failed to fetch, site crashes etc.

[EvanHerman]

It looks like some plugins are throwing an error when installing. I was trying to install WooCommerce but it looks like it errors before installing.

Example URL:
https://playground.wordpress.net/?plugin=woocommerce

Also, I noticed that if you manually install WooCommerce from the dashboard (Plugins > Add New) after a short while the site crashes or just freezes and looks like it goes offline. I'm not able to get passed the WooCommerce Guided Tour. I'm not sure if the two issues are related or not.

[EvanHerman]

Looks like #967 is related

[adamziel]

Thank you for reporting @EvanHerman! Which browser is this? The error on your first screenshot seems to be a failing fetch() request to plugins.wp.org – the browser was unable to download the WooCommerce.zip file.

The fetch_error messages combined with "You are probably offline" on the second screenshot seem to confirm that hypothesis.

The "sad face" error should never be there so there may be a Playground crash involved somewhere in the process, but it seems like the largest issue is the browser being offline.

[EvanHerman]

Thanks @adamziel! This was in Chrome. Maybe the WordPress APi was temporarily down or something. Installing WooCommerce works fine now. I think you are right about the fetch_error. While there was a notice in the console, the playground still works fine.

However, the other issue with the sad face and playground crashing, it looks like this is still happening on my end in the playground I have hosted. And it only appears to happen with WooCommerce installed. I'm getting the following crash consistently. I can only get through the 'Guided Setup' within Woo and then a 30ish or so seconds later playground crashes.

RuntimeError: null function or function signature mismatch
at 015427c2:0xe859
at 015427c2:0x1e17a
at 015427c2:0x4e17
at 015427c2:0x3ca346
at 015427c2:0x897d
at 015427c2:0x28a609
at e. (php_8_0-0ca95816.js:4:6601)
at e.asm. (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:1:2773)
at zo (php_8_0-0ca95816.js:4:17084)
at 015427c2:0x3ca527

Error: null function or function signature mismatch
at #handleRequest (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:52:3848)
at async WebPHP.run (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:41:11357)
at async #l (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:41:2891)
at async PHPRequestHandler.request (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:41:1377)
at async PHPBrowser.request (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:35:4937)

RuntimeError: memory access out of bounds
at wasm://wasm/015427c2:wasm-function[3913]:0x2aa549
at wasm://wasm/015427c2:wasm-function[3521]:0x289de0
at e. (https://playground.dev.test/assets/php_8_0-0ca95816.js:4:6601)
at e.asm. (https://playground.dev.test/worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:1:2773)
at Xo (https://playground.dev.test/assets/php_8_0-0ca95816.js:4:18000)
at wasm://wasm/015427c2:wasm-function[3713]:0x29c611
at wasm://wasm/015427c2:wasm-function[3521]:0x289de0
at e. (https://playground.dev.test/assets/php_8_0-0ca95816.js:4:6601)
at e.asm. (https://playground.dev.test/worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:1:2773)
at Xo (https://playground.devtest/assets/php_8_0-0ca95816.js:4:18000)

Error: 
"unreachable" WASM instruction executed.

The typical reason is a PHP function missing from the ASYNCIFY_ONLY
list when building PHP.wasm.

You will need to file a new issue in the WordPress Playground repository
and paste this error message there:

https://github.com/WordPress/wordpress-playground/issues/new

If you're a core developer, the typical fix is to:

* Isolate a minimal reproduction of the error
* Add a reproduction of the error to php-asyncify.spec.ts in the WordPress Playground repository
* Run 'npm run fix-asyncify'
* Commit the changes, push to the repo, release updated NPM packages

Below is a list of all the PHP functions found in the stack trace to
help with the minimal reproduction. If they're all already listed in
the Dockerfile, you'll need to trigger this error again with long stack
traces enabled. In node.js, you can do it using the --stack-trace-limit=100
CLI option: 

    * <unknown>

    at #handleRequest (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:52:3848)
    at async WebPHP.run (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:41:11357)
    at async #l (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:41:2891)
    at async PHPRequestHandler.request (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:41:1377)
    at async PHPBrowser.request (worker-thread-d6a2a746.js?wpVersion=6.4&phpVersion=8.0&networking=yes&storage=none:35:4937)

So it seems like the service worker or something inside of worker-thread-d6a2a746.js is crashing when Woo is active. It may be something on my end with how things are setup, because it seems like it's working fine at https://playground.wordpress.net/?plugin=woocommerce.

Any clues what might be causing this crash with Woo? I've been trying to track it down for a few days but can't pinpoint it.

[EvanHerman]

Just an update:

• Crashes with PHP 8.0, and 8.3.
• Only crashes in the dashboard (/wp-admin). Front of site does not crash.

[adamziel]

Oh nice, good find!

It's almost certainly this issue:

#251

Here's a recent report related to iterators:

#1147

Here's how to fix that crash:

1. Rebuild PHP with -g2 to preserve the function names
2. Trigger the crash
3. Add all the PHP functions from the stack trace mentioning the "unreachable" instruction to ASYNCIFY_ONLY
4. Rebuild until there's no more crashes

If you found the PHP code snippet that triggers the crash, this could be auto-fixed by creating a new test case as described in

#273

[adamziel]

Also CC @bgrgicak who's got experience with Woo and those Asyncify issues

[adamziel]

I wonder how much larger would the PHP build with -O3 -g2 would be. If that's around 100-200kb, it would be handy to ship it to production. Alternatively, a source map or a DWARF file could be handy to decode these stack traces.

[bgrgicak]

it looks like this is still happening on my end in the playground I have hosted.

@EvanHerman do you mean that your site isn't using Playground.WordPress.net, but a self-hosted version of Playground?
If yes how outdated is it? We recently fixed a similar WooCommerce issue #1078.

[bgrgicak]

I wonder how much larger would the PHP build with -O3 -g2 would be. If that's around 100-200kb, it would be handy to ship it to production. Alternatively, a source map or a DWARF file could be handy to decode these stack traces.

If we introduce a debug mode that's being discussed here #1146 it would be nice to load a version of PHP built with -g2 and source maps.

[adamziel]

I checked and -g2 adds 200kb – let's just ship it as it will make debugging so much easier. Source maps could be useful as a separate artifact for use during the debugging, but I wouldn't load them by default in production.

[adamziel]

@EvanHerman is this issue resolved on your end now with the latest version of Playground? Or is it still happening? If it's still happening, please share the new error output as it will contain additional useful debugging information.

[adamziel]

Since we've patched a bunch of these crashes and the reporter did not provide information to confirm whether it still crashes, I'm going to optimistically close this issue. I'm happy to reopen if anyone reproduces that WooCommerce crash.