Joyee Cheung
Joyee Cheung
By the way if a core dump is available that would make it easier to get to clues about what was happening.
IIUC this and OP were both running into issues in a similar setup in https://github.com/actions/setup-node/issues/887 (with GitHub actions)? From the OP of that issue, I suspect the caching GitHub does...
Also, I am not sure if it still works on v20, but can you try using LLDB and https://github.com/nodejs/llnode to see if you can print the JS stack trace (the...
From some quick search, it seems pnpm is using v8-compile-cache: https://github.com/search?q=repo%3Apnpm%2Fpnpm%20v8-compile-cache&type=code And yarn seems to use that too, though I am not able to find where the code is: https://github.com/yarnpkg/berry/issues/5987...
> I suspect node::contextify::ContextifyScript might be the root cause of this The root cause was likely incorrect cache usage by a user land package or corrupted cache provided by user...
> I'm not sure if this is the same issue, though the failure message is the same. The message indicates an `UNREACHABLE()` assertion is reached within V8, this is likely...
It seems people have started conflicting other crashes with this one. - If you see something like `int v8::internal::Deserializer::ReadSingleBytecodeData` - If you or your dependencies is using the [v8-compile-cache](https://www.npmjs.com/package/v8-compile-cache) package,...
When code cache or snapshot is generated, the executable needs to be run to produce those. Are you running the executable using a simulator to generate the preparation blob?
I see that the postject issue mentions that it showed up on macOS and from the crash report the executable is translated by Rosetta, during the blob generation V8 probably...
> Then I created the preparation blob and injected it into all four target executables, using the darwin-arm64 version of Node. I see, in that case it's less likely to...