FATAL ERROR: v8::FromJust Maybe value is Nothing #6899
Comments
|
Reproduced on 32 bit 0.12.7 nodejs
|
|
debug build stack trace: |
|
@addaleax I'd like to investigate further. How did you reproduce the crash ? |
|
@targos Hm, I’m looking into it too, and for me (x64, Linux) it reproduces it exactly as described above… |
|
So, the node/deps/v8/src/js/messages.js Lines 208 to 215 in 7c3e920 |
|
Minimal reproduction: function a() {
try {
a();
} catch (e) {
console.log(e);
}
}
a();I think what’s going on is that once the |
addaleax
added
vm
|
PR: #6907 |
Make less assumptions about what objects will be available when vm context creation or error message printing fail because V8 runs out of JS stack space. Ref: nodejs#6899
Don't cache the exported values of fully uninitialized builtins. This works by adding an additional `loading` flag that is only active during initial loading of an internal module and checking that either the module is fully loaded or is in that state before using its cached value. This has the effect that builtins modules which could not be loaded (e.g. because compilation failed due to missing stack space) can be loaded at a later point. Fixes: nodejs#6899
Make less assumptions about what objects will be available when vm context creation or error message printing fail because V8 runs out of JS stack space. Ref: nodejs#6899
Don't cache the exported values of fully uninitialized builtins. This works by adding an additional `loading` flag that is only active during initial loading of an internal module and checking that either the module is fully loaded or is in that state before using its cached value. This has the effect that builtins modules which could not be loaded (e.g. because compilation failed due to missing stack space) can be loaded at a later point. Fixes: nodejs#6899
Make less assumptions about what objects will be available when vm context creation or error message printing fail because V8 runs out of JS stack space. Ref: nodejs#6899 PR-URL: nodejs#6907 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Don't cache the exported values of fully uninitialized builtins. This works by adding an additional `loading` flag that is only active during initial loading of an internal module and checking that either the module is fully loaded or is in that state before using its cached value. This has the effect that builtins modules which could not be loaded (e.g. because compilation failed due to missing stack space) can be loaded at a later point. Fixes: nodejs#6899 PR-URL: nodejs#6907 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Don't cache the exported values of fully uninitialized builtins. This works by adding an additional `loading` flag that is only active during initial loading of an internal module and checking that either the module is fully loaded or is in that state before using its cached value. This has the effect that builtins modules which could not be loaded (e.g. because compilation failed due to missing stack space) can be loaded at a later point. Fixes: #6899 PR-URL: #6907 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Don't cache the exported values of fully uninitialized builtins. This works by adding an additional `loading` flag that is only active during initial loading of an internal module and checking that either the module is fully loaded or is in that state before using its cached value. This has the effect that builtins modules which could not be loaded (e.g. because compilation failed due to missing stack space) can be loaded at a later point. Fixes: #6899 Ref: #6899 PR-URL: #6907 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Don't cache the exported values of fully uninitialized builtins. This works by adding an additional `loading` flag that is only active during initial loading of an internal module and checking that either the module is fully loaded or is in that state before using its cached value. This has the effect that builtins modules which could not be loaded (e.g. because compilation failed due to missing stack space) can be loaded at a later point. Fixes: #6899 Ref: #6899 PR-URL: #6907 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
|
I just got this today with node 8.11.1. It happens when I do an infinite recursion in my graphQL resolver. The resolver is probably called as function and awaited. I'll probably setup a small repro repo and report it as a new issue. |
|
Just randomly hit this myself. No clue what I did to cause this. The command that caused this was |
|
Same here @OmgImAlexis Using Vitejs 3.0.0 and Vitest 0.18.0 My tests seem to be passing, but there are 3 unhandled rejection errors. |
|
I meet the same question, too~ |
|
Just want to chime in with my vitest experience – I ran into the same obscure errors and was able to resolve them by fixing the following:
I was able to debug/verify the changes by editing the files in node_modules directly until they worked (and updated the package src afterward – this was just faster for me than doing the build for each change) |
|
I also encountered this problem when using vitest again |
|
This year's commenters: you're commenting on an old report that just happens to have the same generic error message in it. It's almost certainly not the same bug though, too much water has passed under too many bridges for that. See #43304 for a more recent report. There's an excellent chance it's already fixed in the latest release. |
|
I'm still getting the same issue, that post you linked to states it's fixed but using a newer version of node still throws this. |
|
Just update vitest to the latest version, it worked for me |
|
@Radinax I've updated to |
|
Yes, I was facing this issue with Vitest 0.25.8 and node v18.0.0 in NX. I managed to fix this issue by cleaning the npm cache and downgrading to node version 16, npm cache clean --force |
|
I'm going to lock this. This is one of those issues that show up high in search rankings but as I mentioned in #6899 (comment), it's a generic error message - in 2023 you're not hitting the bug that was found and fixed in 2016. If you're still seeing that error message with recent releases (and note: v18.0.0 does not count as recent, that would be v18.14.0 at the time of writing), then please open new issues with steps to reproduce, preferably without involving third-party dependencies. |
People coming here from search engines, read #6899 (comment)
segmentation fault when simple mqtt client tries to send 40kb data to broker.
4.x versions of node crash with "console.log is not a function"
Program does not crash when i remove the // before the first console.log.
Seems to work under 32 bit.
steps to reproduce:
The text was updated successfully, but these errors were encountered: