-
-
Notifications
You must be signed in to change notification settings - Fork 31.5k
node_contextify: do not incept debug context #4819
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
Can you also add a test for this? |
ScopedEnvironment env_scope(debug_context, env); | ||
const int index = Environment::kContextEmbedderDataIndex; | ||
if (!debug_context->GetAlignedPointerFromEmbedderData(index)) { | ||
ScopedEnvironment env_scope(debug_context, env); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure this is right? env_scope
's destructor will get called as soon as execution moves outside of the if
statement. I'm not sure, but we may need to have an if-else
and copy the code after the current if
into both blocks (one with env_scope
and one without)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the heads up. I have not used structs with this pattern before and was unaware of the semantics.
@mscdex I've attempted a different approach, does this solve your original concerns? |
6608d57
to
c9f8309
Compare
@@ -246,14 +246,22 @@ class ContextifyContext { | |||
// there is no way for the embedder to tell if the data index is | |||
// in use. | |||
struct ScopedEnvironment { | |||
bool alreadyInDebugContext = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style: C++ code uses snake_case for locals.
EDIT: And data members use snake_case and end in an underscore: bool already_in_debug_context_ = false;
Also, it should go near the definition of context_
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rebased in those style changes in case we decide to move forward with 803ca9667a8dc608c5271633e42e792dbba66fc0
9dcfa74
to
428ac5f
Compare
@bnoordhuis I've just pushed another option for handling this problem. @ofrobots was saying that my second attempt would cause a FATAL ERROR if the index slot didn't exist The current approach, originally done as a patch shared by ofrobots does away with that, but no longer cleans up the debugger context, which may be undesirable |
428ac5f
to
56d54df
Compare
@@ -0,0 +1,3 @@ | |||
var util = require('util'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'use strict'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bah... didn't mean to check that in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
killed that file.
LGTM with a nit and assuming the CI likes it. |
56d54df
to
d491ddf
Compare
@bnoordhuis can I get you to sign off one more time on the current head. Just want to ensure that is the one you were ok with |
LGTM but is there a reason you're not deassigning the context slot afterwards? |
the deassignment was what was causing the original problem MylesBorins@724fb28 offers an approach with deassignment but causes the debug errors mentioned above. TBQH I am a little out of my depth here, and not sure the best way to only deassign if there was not already a debugger context |
What worries me a little is that you're essentially leaving a dangling pointer. If you have a simple regression test, I can take a look. |
@bnoordhuis See: #4815. The original problem is that there is code in util.js (e.g. I am worried about the dangling pointer, but I think Environment lives longer as the debug context so I am not sure it really is dangling? |
Not now, no, but it's a future hazard. Change itself LGTM but a regression test would be good. |
@bnoordhuis are there similar regression tests I can look at to base it off of? |
Maybe the test from 25776f3? |
So the edge case does not seem to show up if debugger is being run in interactive mode. Not having a ton of luck here |
d491ddf
to
c0efa65
Compare
Yeah, this one is a hard one. The change LGTM but it leaves me a bit uneasy. Unfortunately I haven't had any luck coming up with an idea for a reliable regression test either. |
c0efa65
to
86a94ac
Compare
ping @bnoordhuis |
proc.stderr.setEncoding('utf8'); | ||
|
||
function fail() { | ||
assert(false, 'the program should not hang'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: common.fail()
Test LGTM. Would be great if @bnoordhuis or @indutny or someone else knowledgable about the C++ side of things could give an |
LGTM if CI is happy. |
// exploding but is still not an elegant solution. Likely a deeper bug | ||
// causing this problem. | ||
proc.stdin.on('error', (err) => { | ||
console.error(new Error(err)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
err
is already an Error, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
LGTM with teeny tiny nits. Can I suggest you stress-test the test besides doing the regular CI? |
9b84a8c
to
54b8693
Compare
Stress Test: https://ci.nodejs.org/job/node-stress-single-test/415/ edit: stress test had over 1400 positives and 0 negatives so I stopped it. |
54b8693
to
86aa7db
Compare
Currently a debug context is created for various calls to util. If the node debugger is being run the main context is the debug context. In this case node_contextify was freeing the debug context and causing everything to explode. This change moves around the logic and no longer frees the context. There is a concern about the dangling pointer The regression test was adapted from code submitted by @3y3 in nodejs#4815 Fixes: nodejs#4440 Fixes: nodejs#4815 Fixes: nodejs#4597 Fixes: nodejs#4952 PR-URL: nodejs#4815 Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Rich Trott <rtrott@gmail.com>
86aa7db
to
4897f94
Compare
landed in 4897f94 |
Notable changes: * buffer: make byteLength work with Buffer correctly (Jackson Tian) - nodejs#4738 * debugger: guard against call from non-node context (Ben Noordhuis) - nodejs#4328 * node_contextify: do not incept debug context (Myles Borins) - nodejs#4819 * deps: update to http-parser 2.5.2 (James Snell) - nodejs#5238
Notable changes: * buffer: make byteLength work with Buffer correctly (Jackson Tian) - #4738 * debugger: guard against call from non-node context (Ben Noordhuis) - #4328 * node_contextify: do not incept debug context (Myles Borins) - #4819 * deps: update to http-parser 2.5.2 (James Snell) - #5238 PR-URL: #5200 (comment)
Currently a debug context is created for various calls to util.
If the node debugger is being run the main context is the debug
context. In this case node_contextify was freeing the debug context
and causing everything to explode.
This change checks to see if there is currently a debug context
before setting up / tearing down a temporary context.