-
Notifications
You must be signed in to change notification settings - Fork 29.5k
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
How to detect debug mode #9617
Comments
Check out the discussion in #7102. |
@cjihrig That's useful to know, but I'd like to have a solution without that flag: just another way to know if the process is in the debug mode (maybe some environment variable which is set by the debugger or something like that)? Thanks! |
Why would you care whether the process is being debugged or not? To answer your question, there is no real way to determine if the debugger is active (that is future proof.) |
@bnoordhuis There are some features I want to disable in the debug mode to make the debugging easier. That's pretty much it. |
You can only divine it indirectly. For example, |
Another possible way to check for debug mode (asynchronously) is to simply try to bind to the debug port: function isDebugging(cb) {
require('net').createServer().on('error', function(err) {
if (err.code === 'EADDRINUSE')
cb(null, true);
else
cb(err);
}).listen(process.debugPort, function() {
this.close();
cb(null, false);
});
} |
@mscdex Thanks! I'd prefer a sync version, tho. Actually, isn't possible just to set an environment variable or a global (like before) when debugging? |
@IonicaBizau Well, if you are adventurous and don't mind relying on a "private" API, here is a synchronous version of my above solution.... function isDebugging() {
var TCP = process.binding('tcp_wrap').TCP;
var tcp = new TCP();
var r;
function doBind() {
var err = tcp.bind6('::', process.debugPort);
if (err)
err = tcp.bind('0.0.0.0', process.debugPort);
return err;
}
doBind();
r = doBind();
if (r) {
tcp.close();
return false;
}
return true;
} |
I think this has been answered. Closing. |
@mscdex Thanks for that! 👍 |
@mscdex That code returns true even another process is being debugged. Is there any way to tell if the current process is debugged? |
It seems more simple way is to check execArgv. In DEBUG mode there should be 'debug' or 'inspect' word in argument's list.
|
See https://nodejs.org/api/inspector.html Note that there is no special "debug mode". What you may detect is whether or not inspector WebSocket server is running. Another is if there's any inspector session connected (currently you can create the session through the WebSocket connection or by using the JS API). Currently you can detect ongoing session by trying to connect another one and then catching this exception - but this will most likely stop working down the line once concurrent sessions are supported. |
@eugeneo Right, if inspection is initiated programmatically my method is useless, however if the project isn't a public library, so developers are fully in control of how debug can be initiated, then execArgv check would be sufficient. |
As said @zurgul, checking
I also thought about sending a request to:
but a The only reliable solution to me is the one mentioned by @mscdex const REJECT = new Error('Action refused, The UI process is not in debug mode');
const authorize = () => new Promise((resolve, reject) => net.createServer()
.on(
'error',
({ code }) => ((code === 'EADDRINUSE') ? resolve() : reject(REJECT))
)
.listen(process.debugPort, function () {
this.close();
reject(REJECT);
})
); It would be awesome if we could have a |
One use case I ran into was to set the timeout for tests to infinity if I'm stepping through the code, instead of the test timing out after the 5-second default timeout limit. Should this issue be reopened? |
In my context, I have a side inspect protocol that must accept requests only if the process is in debug/inspect mode. @dandv I'd love to see it reopened, I think the cost would be minimal to have it natively |
There should definitely be a standard easy-to-use method to detect whether the process is running on debug mode or not. The most reliable solution at the moment seems to be to pass a flag initially, and spawn child processes with this flag if it also is present in the parent. This is annoying and should be unnecessary. There should also be an option when spawning children that enables inspect if and only if the parent is also in inspect mode. |
I think we should do this - any strong opinions ? |
The question "how to detect debug mode" is wrong though. The debugger (inspector) is always enabled. A better question is "is a client attached" but that's still kind of the wrong thing to ask because a client might be tracing or profiling but not debugging. "Has the |
@bnoordhuis there is some method of debugging that 99% of users use (myself included). I think that what's important is that there is a native way to easily detect that |
So what definition of debugging is that? When stepping? When breakpoints are set? When the script is paused? (You wouldn't be able to detect that last one, of course!) As to your 99% argument: it's only a matter of time before people start opening issues complaining our naive new API doesn't work for their legitimate use cases. "Good enough" often isn't. |
Not if in the docs you state that this works only if ... . Also, people
complaining about issues is expected for every feature and should even be
encouraged. It's not by any means a reason not to implement a feature lol
…On Thu, Aug 15, 2019, 5:23 PM Ben Noordhuis ***@***.***> wrote:
So what definition of debugging is that? When stepping? When breakpoints
are set? When the script is paused?
(You wouldn't be able to detect that last one, of course!)
As to your 99% argument: it's only a matter of time before people start
opening issues complaining our naive new API doesn't work for their
legitimate use cases. "Good enough" often isn't.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#9617?email_source=notifications&email_token=ADLB3ZDCYBIJDPR6GH2FCXDQEW3LFA5CNFSM4CWKRDX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4M4O2I#issuecomment-521783145>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADLB3ZBWKKBAAUKOBW4TIE3QEW3LFANCNFSM4CWKRDXQ>
.
|
I can tell you from almost 10 years of experience as a Node.js maintainer that it never works that way.
A badly designed feature? For me that'd be plenty of reason. The point still stands that the ask is poorly defined. You never answered what constitutes your definition of "debug mode." Neither is it clear to me when it's relevant to know that. If it's to work around timing sensitive code, then make it less timing sensitive. What other reasons are there? |
@nicszerman I understand you want this to happen but listen to Ben here. It is important that we detect the right thing and we expose an API that is not misleading:
What I'd like see core expose (names and functionality obviously subject to bikeshed):
This will only expose the capabilities from core and let users decide what's best for their apps on their own rather than us exposing an incomplete API that hides capabilities. @nodejs/inspector @bnoordhuis wdyt? |
That's certainly closer to what I had in mind. There is a practical snag however. Right now our inspector glue code doesn't interpret protocol messages at all, it just passes them to and from the inspector backend (i.e., V8.) We don't want to be in the business of parsing/interpreting them because that's very fragile. The protocol changes frequently and even the wire format is in flux. Chromium is switching from JSON to a binary format for efficiency reasons. In order for your proposal to work, V8's C++ inspector API would need to grow a number of new methods and callbacks. That requires cooperation from the V8 team and someone willing to do the work. Whether the effort involved is proportional to the payoff remains to be seen. I'm not volunteering at any rate. ^^ |
@nodejs/v8 @hashseed is this something you are willing to expose? ^ @bnoordhuis as far as I know the binary stuff has stopped because it didn't actually improve performance but I am sure I am not updated. |
I would certainly be possible for every inspector domain to expose an |
@hashseed basically, I want to have a different behavior when the debugger is enabled (for example in order to emit less optimized but easier to debug code). |
My use case of this feature is that I want to use a different log level when debugger is present. Detecting debuggers by |
@bin-y That sounds reasonable. A generic Can you open a new issue and link back to this one? |
Hi @bnoordhuis ,
I agree with your opinion and I was not meant to do that. I didn't notice the
If I need to change log level dynamically in the future, I'll try your idea by checking |
Any news on this topic? My use case is that I want mocha test timeout to be Infinity when I'm debugging it. (default is 2 seconds) For now, I'm using the |
@leonardoraele I had the same debug timeout request back in 2019. |
In
7.0.0
, looks like thetypeof v8debug
always returnsundefined
. How to detect if the process is running in the debug mode?The text was updated successfully, but these errors were encountered: