-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
doc, test: document and test vm timeout escapes #23743
Conversation
// it to fail reliably | ||
if ((current - start) / NS_PER_MS >= 50n) { | ||
throw new Error( | ||
`escaped timeout at ${(current - start) / NS_PER_MS} milliseconds!`); |
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: how about caching the result instead of recomputing it?
I've run the example in all supported versions, last nightly and canary and every time I've got: Error: Script execution timed[ out after 5ms] and then the node exited and no infinite loops happened. Would it be confusing for a reader that would test the example? |
@vsemozhetbyt ... I assume you're copying the example to a file then running it? If so, the unhandled error crashes the process. I've removed the second call to |
Yes, I often test examples in file scripts) |
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.
In the documentation, I would additionally drive home the fact that the timeout is not a security sandboxing mechanism, and that a more comprehensive solution could be running the untrusted code in a complete separate process. Overall looks good.
@TimothyGu ... there is already a warning in there for that, I believe. Doesn't mean it can't be made better but let's save that for a different PR. |
Please 👍 to fast-track |
Unfortunately the new tests here are flaky. Will have to investigate |
ac777ae
to
5066c53
Compare
Using `process.nextTick()`, `Promise`, or `queueMicrotask()`, it is possible to escape the `timeout` set when running code with `vm.runInContext()`, `vm.runInThisContext()`, and `vm.runInNewContext()`. This documents the issue and adds three known_issues tests. Refs: nodejs#3020
These are known issues that can be flaky on certain platforms because they rely entirely on timing differences.
5066c53
to
47a2cb5
Compare
Unfortunately, the known_issue tests appear to be inherently flaky due to the reliance on timing differences for them to fail. Marking them flaky in a separate commit. Not sure if there's a way to make them fail more reliably but having the known_issue tests in there, flaky or otherwise, is still generally a good idea. New CI: https://ci.nodejs.org/job/node-test-pull-request/18117/ |
Using `process.nextTick()`, `Promise`, or `queueMicrotask()`, it is possible to escape the `timeout` set when running code with `vm.runInContext()`, `vm.runInThisContext()`, and `vm.runInNewContext()`. This documents the issue and adds three known_issues tests. Refs: #3020 PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
These are known issues that can be flaky on certain platforms because they rely entirely on timing differences. PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Using `process.nextTick()`, `Promise`, or `queueMicrotask()`, it is possible to escape the `timeout` set when running code with `vm.runInContext()`, `vm.runInThisContext()`, and `vm.runInNewContext()`. This documents the issue and adds three known_issues tests. Refs: #3020 PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
These are known issues that can be flaky on certain platforms because they rely entirely on timing differences. PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Looks like the test may be flaky...https://ci.nodejs.org/job/node-test-commit-smartos/21423/nodes=smartos16-64/console I'll open an issue. |
will hold off on landing in LTS until it is clearly not flaky |
test-vm-timeout-escape-promise is still marked as flaky in the status file. Not sure how often it actually flakes, though. |
Using `process.nextTick()` or `Promise`, it is possible to escape the `timeout` set when running code with `vm.runInContext()`, `vm.runInThisContext()`, and `vm.runInNewContext()`. This documents the issue and adds two known_issues tests. Refs: #3020 PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
These are known issues that can be flaky on certain platforms because they rely entirely on timing differences. PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Using `process.nextTick()` or `Promise`, it is possible to escape the `timeout` set when running code with `vm.runInContext()`, `vm.runInThisContext()`, and `vm.runInNewContext()`. This documents the issue and adds two known_issues tests. Refs: #3020 PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
These are known issues that can be flaky on certain platforms because they rely entirely on timing differences. PR-URL: #23743 Refs: #3020 Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Finally getting back to this one ;-)
Using
process.nextTick()
,Promise
, orqueueMicrotask()
, itis possible to escape the
timeout
set when running code withvm.runInContext()
,vm.runInThisContext()
, andvm.runInNewContext()
.This documents the issue and adds three known_issues tests.
Refs: #3020
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes