-
Notifications
You must be signed in to change notification settings - Fork 30.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
Memory leak when awaiting in inspector Debugger.pause
callback
#51397
Comments
cc @legendecas @joyeecheung any suggestions? |
The retained scope information with For instance: session.on("Debugger.paused", (event) => {
// Call 'Debugger.resume' synchronously to release the remote object in `event`.
session.post("Debugger.resume");
}); Notably, using breakpoints with a same-thread inspector session is not a good practice because the inspected script can not be distinguished from the inspector session codes and the program is literally been resumed when the |
The issue is that the debugger resumes on it's own when I call For example, see this full code example I posted to a discussion: I had to add
So it not possible to call anything asynchronous from within the |
I think you can use the example as follows. import { Session } from "node:inspector";
const session = new Session();
session.connect();
session.on("Debugger.paused", async (event) => {
for (const frame of event.params.callFrames) {
const localScope = frame.scopeChain.find((scope) => scope.type === "local");
if (localScope?.object?.objectId) {
session.post("Runtime.getProperties", {
objectId: localScope.object.objectId,
ownProperties: true,
}, (err, result) => {
// console.log("Runtime.getProperties");
});
}
}
session.post("Debugger.resume");
});
session.post("Debugger.enable", (err) => {
!err && session.post("Debugger.setPauseOnExceptions", { state: "all" });
});
setInterval(() => {
console.log(`${Math.floor(process.memoryUsage().rss / 1024 / 1024)} MB`);
}, 1000);
setInterval(() => {
try {
throw new Error("Hello");
} catch {}
}, 100); because VM will call resume after |
As mentioned above, it is not recommended to use breakpoints with same thread inspector sessions. Instead, try to connect to the inspector with websocket connections or with a worker thread: import { Session } from "node:inspector/promises";
import { Worker, isMainThread } from 'node:worker_threads';
if (!isMainThread) {
inspectMainThread();
} else {
mainThreadWork();
new Worker(new URL(import.meta.url));
.on('exit', (code) => console.log('worker exited', code));
}
function mainThreadWork() {
setInterval(() => {
try {
throw new Error("Hello");
} catch {}
}, 1);
}
async function inspectMainThread() {
setInterval(() => {
console.log(`${Math.floor(process.memoryUsage().rss / 1024 / 1024)} MB`);
}, 1000);
const session = new Session();
session.connectToMainThread();
session.on("Debugger.paused", async (event) => {
// `await` can be used here.
// After all asynchronous work is done, resume the main thread.
session.post('Debugger.resume');
});
await session.post("Debugger.enable");
await session.post("Debugger.setPauseOnExceptions", { state: "all" });
} |
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: #51417 Fixes: #51397 Reviewed-By: Luigi Pinca <[email protected]>
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: nodejs#51417 Fixes: nodejs#51397 Reviewed-By: Luigi Pinca <[email protected]>
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: nodejs#51417 Fixes: nodejs#51397 Reviewed-By: Luigi Pinca <[email protected]>
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: nodejs#51417 Fixes: nodejs#51397 Reviewed-By: Luigi Pinca <[email protected]>
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: #51417 Fixes: #51397 Reviewed-By: Luigi Pinca <[email protected]>
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: nodejs#51417 Fixes: nodejs#51397 Reviewed-By: Luigi Pinca <[email protected]>
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: #51417 Fixes: #51397 Reviewed-By: Luigi Pinca <[email protected]>
Setting breakpoints with a same-thread inspector session should be avoided because the program being attached and paused is exactly the debugger itself. A worker thread inspector session or a debugger program should be used if breakpoints are needed. PR-URL: #51417 Fixes: #51397 Reviewed-By: Luigi Pinca <[email protected]>
Version
20.10.0
Platform
All
Subsystem
inspector
What steps will reproduce the bug?
The following code leaks memory at about 10MB per second on my machine:
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior? Why is that the expected behavior?
No memory leaked
What do you see instead?
I see ~10MB leaked every second which is around 10kB per debugger pause event.
Additional information
I found that that the following code:
Outputs:
The debugger does not wait for
Debugger.resume
. Instead it resumes automatically as soon as we callawait session.post
and I guess callingRuntime.getProperties
after the resume causes something to be leaked?The text was updated successfully, but these errors were encountered: