-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NodeJS 20 --import, --inspect-brk and Chrome DevTools don't work together (works in NodeJS 18) #53681
Comments
|
As I mention in other tickets, this impacted me for both ts-node and tsimp usage. |
I’ve been working of devtools protocol lately. I could take a look.
…On Tue, 2 Jul 2024 at 1:35 Alexander J. Vincent ***@***.***> wrote:
Version
v20.15.0
Platform
Linux fedora 6.9.6-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 21 15:48:21 UTC 2024 x86_64 GNU/Linux
Subsystem
*No response*
What steps will reproduce the bug?
Google Chrome: Version 126.0.6478.126 (Official Build) (64-bit)
OS: Fedora Linux 40 (Workstation Edition)
1. Create the following files:
loader-hooks/loader.js
export async function initialize() {}
export async function resolve(specifier, context, nextResolve) {
return nextResolve(specifier, context);}
export async function load(url, context, nextLoad) {
return nextLoad(url, context);}
loader-hooks/registration.js
import url from 'node:url'import { register } from 'node:module';
const __filename = url.fileURLToPath(import.meta.url);register(`./loader.js`, url.pathToFileURL(__filename));
build.js
console.log("success");
2. Install nvm, so you can switch between NodeJS 18 and NodeJS 20.
3. Run the following commands from your directory:
nvm use 18
node --import ./loader-hooks/registration.js ./build.js
node --inspect-brk --import ./loader-hooks/registration.js ./build.js
4.
When the debugger for the last command is available, in Google Chrome,
visit chrome://inspect/#devices . You should have a Target link for
./build.js available. Click it, and observe the Chrome DevTools
window. The Play button should be active. You can hit Play and the
debugging session will finish cleanly.
5.
Close the Chrome Developer Tools window, to terminate the debugging
session.
6.
Run the following commands from your directory:
nvm use 20
node --import ./loader-hooks/registration.js ./build.js
node --inspect-brk --import ./loader-hooks/registration.js ./build.js
7. Repeat step 4.
This time you will not have a Play button. The Developer Tools window is
stuck, unable to proceed.
The *only* difference here is Node 20 versus Node 18.
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
The Developer Tools in Google Chrome should be able to step through the
code. This worked when using Node 18 as the debuggee.
What do you see instead?
No ability to step through code or inspect variables. The Developer Tools
are unusable and the NodeJS process is presumably waiting for the Developer
Tools to step forward..
Additional information
I do not know if this is a Google Chrome bug or a NodeJS bug. Somewhere
between the two, the debugging handshake fails.
—
Reply to this email directly, view it on GitHub
<#53681>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEBZUN37BDFXHDFH6UU3AZTZKJC2VAVCNFSM6AAAAABKG3TMEWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM4DKMZVG42TKOI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I'm also hitting this issue. Essentially any call to the new register causes Works in node 20.14.0 broken in 20.15.1 Clicking the pause button in Chrome dev tools reveals that it is stuck here: // node:internal/modules/esm/hooks
// line 587
waitForWorker() {
if (!this.#isReady) {
const { kIsOnline } = require('internal/worker');
if (!this.#worker[kIsOnline]) {
debug('wait for signal from worker');
AtomicsWait(this.#lock, WORKER_TO_MAIN_THREAD_NOTIFICATION, 0); // <----- Paused on this line
const response = this.#worker.receiveMessageSync();
if (response == null || response.message.status === 'exit') { return; }
const { preloadScripts } = this.#unwrapMessage(response);
this.#executePreloadScripts(preloadScripts);
}
this.#isReady = true;
}
} |
Steps for simple reproduction:
|
+1 when debug with tsx (which is --import tsx --inspect-brk) and a method to mitigate:
I don't know what happend, but this does works for me 😂 |
Internal workers are essential to load user scripts and bootstrapped with internal entrypoints. They should not be waiting for inspectors even when `--inspect-brk` and `--inspect-wait` were specified, and avoid blocking main thread to bootstrap. IsolateData can be created with a specified PerIsolateOptions instead of creating a copy from the per_process namespace. This also avoids creating a copy bypassing the parent env's modified options, like creating a worker thread from a worker thread. PR-URL: #54219 Fixes: #53681 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Internal workers are essential to load user scripts and bootstrapped with internal entrypoints. They should not be waiting for inspectors even when `--inspect-brk` and `--inspect-wait` were specified, and avoid blocking main thread to bootstrap. IsolateData can be created with a specified PerIsolateOptions instead of creating a copy from the per_process namespace. This also avoids creating a copy bypassing the parent env's modified options, like creating a worker thread from a worker thread. PR-URL: #54219 Fixes: #53681 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Internal workers are essential to load user scripts and bootstrapped with internal entrypoints. They should not be waiting for inspectors even when `--inspect-brk` and `--inspect-wait` were specified, and avoid blocking main thread to bootstrap. IsolateData can be created with a specified PerIsolateOptions instead of creating a copy from the per_process namespace. This also avoids creating a copy bypassing the parent env's modified options, like creating a worker thread from a worker thread. PR-URL: #54219 Fixes: #53681 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Internal workers are essential to load user scripts and bootstrapped with internal entrypoints. They should not be waiting for inspectors even when `--inspect-brk` and `--inspect-wait` were specified, and avoid blocking main thread to bootstrap. IsolateData can be created with a specified PerIsolateOptions instead of creating a copy from the per_process namespace. This also avoids creating a copy bypassing the parent env's modified options, like creating a worker thread from a worker thread. PR-URL: #54219 Fixes: #53681 Reviewed-By: Yagiz Nizipli <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Version
v20.15.0
Platform
Subsystem
No response
What steps will reproduce the bug?
Google Chrome: Version 126.0.6478.126 (Official Build) (64-bit)
OS: Fedora Linux 40 (Workstation Edition)
loader-hooks/loader.js
loader-hooks/registration.js
build.js
When the debugger for the last command is available, in Google Chrome, visit chrome://inspect/#devices . You should have a Target link for
./build.js
available. Click it, and observe the Chrome DevTools window. The Play button should be active. You can hit Play and the debugging session will finish cleanly.Close the Chrome Developer Tools window, to terminate the debugging session.
Run the following commands from your directory:
This time you will not have a Play button. The Developer Tools window is stuck, unable to proceed.
The only difference here is Node 20 versus Node 18.
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
The Developer Tools in Google Chrome should be able to step through the code. This worked when using Node 18 as the debuggee.
What do you see instead?
No ability to step through code or inspect variables. The Developer Tools are unusable and the NodeJS process is presumably waiting for the Developer Tools to step forward..
Additional information
I do not know if this is a Google Chrome bug or a NodeJS bug. Somewhere between the two, the debugging handshake fails.
The text was updated successfully, but these errors were encountered: