Repository navigation
FATAL archived threads in combination with wasm not supported #29767
Description
- v12.11.0:
- Linux gkj 5.3.0-13-generic test: increase --stack-size to prevent child process failure on ARM #14-Ubuntu SMP Tue Sep 24 02:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux:
v8/src/wasm/wasm-engine.cc:
I get the following error when running the server tests for my package "koru"
server err:
#
# Fatal error in , line 0
# archived threads in combination with wasm not supported
#
#
#
#FailureMessage Object: 0x7f1f90c8b760
This error has never occurred on any previous version of node.
To run the tests you need to have postgres and libpq-dev installed and have superuser access to postgres (sudo -u postgres createuser -drs $USER).
git clone https://github.com/jacott/koru.git
cd koru
npm i
createdb korutest
npm t -- --nodoc -sThe fatal error does not occur on any particular test as far as I can tell.
Activity
addaleax commentedon Sep 29, 2019
Do you use Workers or any native addons (in node_modules or otherwise)? Is there any chance of getting a reproduction with fewer dependencies?
This may be a breaking change in V8 7.7 that we have overlooked.
/cc @nodejs/v8
jacott commentedon Sep 29, 2019
If I comment out the test that uses the package "source-map" (
app/koru/stack-error-convert-test.js) then all the tests pass. If I run the convert-test by itself it runs okay.jacott commentedon Sep 29, 2019
I don't use workers but I do use native addons: package fibers, pg-libpq and koru itself has a small napi file.
Other larger code bases that use koru but don't invoke the source-map code in their tests also run fine.
devsnek commentedon Sep 29, 2019
source-map uses wasm. I can try to debug this a bit when I'm back on my laptop later tonight.
jacott commentedon Sep 30, 2019
Thanks! The problem is not consistent. It mostly fails but sometimes does not. I have also seen it fail when I just run
app/koru/stack-error-convert-test.jsbut not very often. It always succeeds when that test is excluded.devsnek commentedon Sep 30, 2019
tried looking into this a bit, not sure what is going on... going to need the v8 team i think
hashseed commentedon Sep 30, 2019
@jakobkummerow
bnoordhuis commentedon Sep 30, 2019
node-fibers hacks the thread-local storage to trick V8 into thinking it's running separate threads/isolates, that probably has something to do with it.
backes commentedon Sep 30, 2019
Can you please explain in which ways archived threads are used here? We did not expect users of that outside of chrome, and for the chrome use case we do not need to support WebAssembly.
Note that a workaround for node might be to disable wasm code gc by passing --no-wasm-code-gc.
jacott commentedon Oct 1, 2019
using
--no-wasm-code-gcdoes indeed appear to stop the problem occurring.Fix fatal error with wasm gc and node-fibers in node 12.11+
V8 in Node 12 broke fibers. Work around with --no-wasm-code-gc.
jasnell commentedon Jun 19, 2020
It does not appear that there's anything actionable here? Closing. Can reopen if necessary
opyh commentedon Oct 26, 2020
@bnoordhuis
Could you elaborate a bit so we can find out if this is fixable in node-fibers?
Downgrading to wdio 7.8.0 since async/await is not completely working…