Node fatal error: ToggleAsyncHook Cannot toggle Inspector's AsyncHook #27261
Labels
inspector
Issues and PRs related to the V8 inspector protocol
Comments
|
I have a same problem, but only I use debugger in JetBrains PHPStorm |
|
I am also using JetBrains (Webstorm) to debug the application. I see the error under Webstorm, I will have to test if it does not happen outside of Webstorm. |
|
Hi, sorry about not noticing this earlier. Can you still reproduce this in newer versions of v12? |
|
We have a report of this in Node 13.7.0 in VS Code's JavaScript debugger @joyeecheung microsoft/vscode-js-debug#222 |
|
@connor4312 Thanks for the notice. One thing to note with the stack trace in the OP is that this happens when the worker is shutting down, and that's when JS is not supposed to be executed - however our inspector agent is not aware of this and tries to toggle the inspector async hooks to stop tracking async call stacks, which requires JS execution. In microsoft/vscode-js-debug#222 (comment) it happens when the main thread is shutting down. We should probably just return there when JS execution is not allowed, I'll work on a fix, but it would be helpful if there is a reproducible test case. |
joyeecheung
added
the
inspector
|
On a second thought the ordering seems odd, |
|
Got same problem with v14.2.0 and vs-code: |
|
There's another report of something that sounds similar (#33448, H/T @joyeecheung for making the connection), that report also includes a repo with code that at some point produced the crash. |
|
VSCode + Jest + Debugger: |
This was referenced Jul 10, 2020
|
Our new debugger is the default in the latest version of VS Code, and we've since seen increasing numbers of issues coming in for this. It seems most/all are Jest users. It would be great if we could take another look at this issue. cc @joyeecheung (not able to tag the inspector team like you did 🙂 ) |
I noticed this when using the vscode debugger and mocha. Interestingly it was due to no errorbeforeEach(async () => {
trader1 = users.trader1();
trader2 = users.trader2();
});errorbeforeEach(() => {
trader1 = users.trader1();
trader2 = users.trader2();
}); |
|
Thanks for the ping! I think #34362 should fix this as well. |
2 tasks
|
@towry are you still seeing this issue? I just upgraded my version of node to The node.js version indicated in the "About Visual Studio Code" pop up (pasted below) says Error output:
|
|
Same error here with 12.18.3 installed just now, when debugging with Jest in VSCode. |
|
Anna just fixed this issue yesterday -- it will be a little while before it's released in (I assume) a Node 14 build 🙂 |
|
Ah, you're right @connor4312. The PR (#34362) for the change isn't in the |
cjihrig
pushed a commit
that referenced
this issue
Jul 23, 2020
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of #34361. Fixes: #34361 PR-URL: #34362 Fixes: #27261 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
pushed a commit
that referenced
this issue
Jul 27, 2020
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of #34361. Fixes: #34361 PR-URL: #34362 Fixes: #27261 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
@connor4312, @addaleax, @joyeecheung |
|
@0Ams Yes, this should also be part of the next v12.x release, I think. |
|
@addaleax - Thanks for chasing this down! Do you happen to know if there is a separate issue or PR that is tracking this fix in v12.x? |
addaleax
added a commit
that referenced
this issue
Aug 13, 2020
In the termination case, we should not crash. There’s also no harm being done by ignoring the termination exception here, since the thread is about to be torn down anyway. Also, add a guard against running this during shutdown. That is the likely cause of #34361. Fixes: #34361 PR-URL: #34362 Fixes: #27261 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
@matttowerssonos I’ve pushed it to the v12.x staging branch, but as you can see from the schedule, the next v12.x release is planned for September: nodejs/Release#494 /cc @nodejs/lts |
8 tasks
|
Does this means that the "please report this" line is now obsolete? I'm posting my stacktrace anyway, since it's a bit different to the ones above: VSCode, Node 12.18.2. |
environment:{
"jest": "^25.3.0",
"ts-node": "^9.0.0",
"typescript": "^3.8.3"
}$ node -v
v14.6.0{
"name": "Debug Jest Tests",
"type": "node",
"request": "launch",
"runtimeArgs": [
"--inspect-brk",
"${workspaceRoot}/node_modules/.bin/jest",
"--runInBand"
],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"cwd": "${workspaceFolder}",
"port": 9229
}error:Ran all test suites.
Debugger listening on ws://127.0.0.1:53885/fe1b1321-c831-4b41-8f14-2fdb6edbd85f
For help, see: https://nodejs.org/en/docs/inspector
undefined:0
illegal access
FATAL ERROR:
node::inspector::Agent::ToggleAsyncHook Cannot toggle Inspector's AsyncHook, please report this.
1: 0x1012b7fd5 node::Abort() (.cold.1) [/usr/local/bin/node]
2: 0x1000a3fa9 node::Abort() [/usr/local/bin/node]
3: 0x1000a410f node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
4: 0x1000a3fb9 node::FatalError(char const*, char const*) [/usr/local/bin/node]
5: 0x1001735f3 node::inspector::Agent::ToggleAsyncHook(v8::Isolate*, v8::Global<v8::Function> const&) [/usr/local/bin/node]
6: 0x10089d333 v8_inspector::V8Debugger::setAsyncCallStackDepth(v8_inspector::V8DebuggerAgentImpl*, int) [/usr/local/bin/node]
7: 0x1008a4f13 v8_inspector::V8DebuggerAgentImpl::disable() [/usr/local/bin/node]
8: 0x1008be114 v8_inspector::V8InspectorSessionImpl::~V8InspectorSessionImpl() [/usr/local/bin/node]
9: 0x1008be3be v8_inspector::V8InspectorSessionImpl::~V8InspectorSessionImpl() [/usr/local/bin/node]
10: 0x10017445b node::inspector::(anonymous namespace)::ChannelImpl::~ChannelImpl() [/usr/local/bin/node]
11: 0x1001744ce node::inspector::(anonymous namespace)::ChannelImpl::~ChannelImpl() [/usr/local/bin/node]
12: 0x100174d8e node::inspector::NodeInspectorClient::disconnectFrontend(int) [/usr/local/bin/node]
13: 0x100174afb node::inspector::(anonymous namespace)::SameThreadInspectorSession::~SameThreadInspectorSession() [/usr/local/bin/node]
14: 0x10018785c node::inspector::(anonymous namespace)::DeletableWrapper<node::inspector::(anonymous namespace)::MainThreadSessionState>::~DeletableWrapper() [/usr/local/bin/node]
15: 0x1001666ea unsigned long std::__1::__hash_table<std::__1::__hash_value_type<int, std::__1::unique_ptr<node::inspector::Deletable, std::__1::default_delete<node::inspector::Deletable> > >, std::__1::__unordered_map_hasher<int, std::__1::__hash_value_type<int, std::__1::unique_ptr<node::inspector::Deletable, std::__1::default_delete<node::inspector::Deletable> > >, std::__1::hash<int>, true>, std::__1::__unordered_map_equal<int, std::__1::__hash_value_type<int, std::__1::unique_ptr<node::inspector::Deletable, std::__1::default_delete<node::inspector::Deletable> > >, std::__1::equal_to<int>, true>, std::__1::allocator<std::__1::__hash_value_type<int, std::__1::unique_ptr<node::inspector::Deletable, std::__1::default_delete<node::inspector::Deletable> > > > >::__erase_unique<int>(int const&) [/usr/local/bin/node]
16: 0x100187a4e node::inspector::(anonymous namespace)::DeleteRequest::Call(node::inspector::MainThreadInterface*) [/usr/local/bin/node]
17: 0x1001866cd node::inspector::MainThreadInterface::DispatchMessages() [/usr/local/bin/node]
18: 0x10018813e node::CallbackQueue<void, node::Environment*>::CallbackImpl<node::inspector::MainThreadInterface::Post(std::__1::unique_ptr<node::inspector::Request, std::__1::default_delete<node::inspector::Request> >)::$_0>::Call(node::Environment*) [/usr/local/bin/node]
19: 0x100056151 node::Environment::RunAndClearInterrupts() [/usr/local/bin/node]
20: 0x100055a4c node::Environment::RunAndClearNativeImmediates(bool) [/usr/local/bin/node]
21: 0x100055885 node::Environment::CleanupHandles() [/usr/local/bin/node]
22: 0x100055ec2 node::Environment::RunCleanup() [/usr/local/bin/node]
23: 0x10000514a node::FreeEnvironment(node::Environment*) [/usr/local/bin/node]
24: 0x1000e3eec node::NodeMainInstance::Run() [/usr/local/bin/node]
25: 0x1000786d2 node::Start(int, char**) [/usr/local/bin/node]
26: 0x7fff6cdfccc9 start [/usr/lib/system/libdyld.dylib]
[1] 63789 abort env /usr/local/bin/node --runInBand |
|
Is this bug supposed to be fixed in v12.18.4? I still get the error with the same callstack as @dingyanhe 's above. |
No – the fix is in v14.7.0 and will be released in v12.19.0 as well once that is out, you can subscribe to the latter issue to get updates on the release progress
Yes, it’s just a matter of time of waiting for the v12.x release (unless you’re seeing this on v14.7.0+ or v12.19.0+, in which case you best open a new issue. 🙂 ) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version:
Versions I have tested in which the fatal error occurs: 11.14.x, 11.13.x, 11.12.x, 11.11.x, 11.10.x
Version under which the error does not occur: 10.15.3
Platform:
18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64
Subsystem:
Occurs when using the worker_threads module. The fatal error occurs under the worker thread, but as a consequence the whole node process is taken down.
I have a node application that uses multithreading (worker_threads module) to handle some CPU intensive tasks that are triggered by requests over websockets. The main thread handles the ws traffic and creates worker threads to handle the tasks required by the ws request. The worker thread performs the task and returns a result to the main thread. Whenever running this application with versions 11.x I get the error below. The application works without issues when run ontop of Node version 10.15.3 with the experimental flag set.
I have already mentioned this in a comment to:
#26798
The text was updated successfully, but these errors were encountered: