-
Notifications
You must be signed in to change notification settings - Fork 30k
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
investigate flaky test-worker-terminate-http2-respond-with-file #30643
Labels
flaky-test
Issues and PRs related to the tests with unstable failures on the CI.
http2
Issues or PRs related to the http2 subsystem.
worker
Issues and PRs related to Worker support.
Comments
Trott
added
flaky-test
Issues and PRs related to the tests with unstable failures on the CI.
http2
Issues or PRs related to the http2 subsystem.
worker
Issues and PRs related to Worker support.
labels
Nov 25, 2019
It failed locally once today. I wasn't able to reproduce, even with a lot of repetitions and parallelism. |
This failed locally in 1/3000 runs for me. It’s not going to be easy but I’ll try to debug this – it’s most likely coming from #30374, although it’s quite possible that it just uncovered a pre-existing memory leak. |
addaleax
added a commit
to addaleax/node
that referenced
this issue
Nov 26, 2019
This can be necessary, because some parts of the Node.js code base perform cleanup operations in the Immediate callbacks, e.g. HTTP/2. This resolves flakiness in an HTTP/2 test that failed when a `SetImmediate()` callback was not run or destroyed before the `Environment` destructor started, because that callback held a strong reference to the `Http2Session` object and the expectation was that no such objects exist once the `Environment` constructor starts. Another, slightly more direct, alternative would have been to clear the immediate queue rather than to run it. However, this approach seems to make more sense as code generally assumes that the `SetImmediate()` callback will always run; For example, N-API uses an immediate callback to call buffer finalization callbacks. Unref’ed immediates are skipped, as the expectation is generally that they may not run anyway. Fixes: nodejs#30643
3 tasks
See #30666 for a fix |
addaleax
added a commit
that referenced
this issue
Nov 28, 2019
Guard against running `SetImmediate()` from the destructor. The object will not be alive or usable in the callback, so it does not make sense to attempt to schedule the `SetImmediate()`. PR-URL: #30666 Fixes: #30643 Refs: #30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax
added a commit
that referenced
this issue
Nov 28, 2019
This can be necessary, because some parts of the Node.js code base perform cleanup operations in the Immediate callbacks, e.g. HTTP/2. This resolves flakiness in an HTTP/2 test that failed when a `SetImmediate()` callback was not run or destroyed before the `Environment` destructor started, because that callback held a strong reference to the `Http2Session` object and the expectation was that no such objects exist once the `Environment` constructor starts. Another, slightly more direct, alternative would have been to clear the immediate queue rather than to run it. However, this approach seems to make more sense as code generally assumes that the `SetImmediate()` callback will always run; For example, N-API uses an immediate callback to call buffer finalization callbacks. Unref’ed immediates are skipped, as the expectation is generally that they may not run anyway. Fixes: #30643 PR-URL: #30666 Refs: #30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax
added a commit
that referenced
this issue
Nov 30, 2019
addaleax
added a commit
that referenced
this issue
Nov 30, 2019
Guard against running `SetImmediate()` from the destructor. The object will not be alive or usable in the callback, so it does not make sense to attempt to schedule the `SetImmediate()`. PR-URL: #30666 Fixes: #30643 Refs: #30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax
added a commit
that referenced
this issue
Nov 30, 2019
This can be necessary, because some parts of the Node.js code base perform cleanup operations in the Immediate callbacks, e.g. HTTP/2. This resolves flakiness in an HTTP/2 test that failed when a `SetImmediate()` callback was not run or destroyed before the `Environment` destructor started, because that callback held a strong reference to the `Http2Session` object and the expectation was that no such objects exist once the `Environment` constructor starts. Another, slightly more direct, alternative would have been to clear the immediate queue rather than to run it. However, this approach seems to make more sense as code generally assumes that the `SetImmediate()` callback will always run; For example, N-API uses an immediate callback to call buffer finalization callbacks. Unref’ed immediates are skipped, as the expectation is generally that they may not run anyway. Fixes: #30643 PR-URL: #30666 Refs: #30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
pushed a commit
to addaleax/node
that referenced
this issue
Apr 1, 2020
This was overlooked in a489583. Refs: nodejs#30374 PR-URL: nodejs#30666 Fixes: nodejs#30643 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
pushed a commit
to addaleax/node
that referenced
this issue
Apr 1, 2020
This is in preparation for running native `SetImmediate()` callbacks during shutdown. PR-URL: nodejs#30666 Fixes: nodejs#30643 Refs: nodejs#30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
pushed a commit
to addaleax/node
that referenced
this issue
Apr 1, 2020
Guard against running `SetImmediate()` from the destructor. The object will not be alive or usable in the callback, so it does not make sense to attempt to schedule the `SetImmediate()`. PR-URL: nodejs#30666 Fixes: nodejs#30643 Refs: nodejs#30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
pushed a commit
to addaleax/node
that referenced
this issue
Apr 1, 2020
This can be necessary, because some parts of the Node.js code base perform cleanup operations in the Immediate callbacks, e.g. HTTP/2. This resolves flakiness in an HTTP/2 test that failed when a `SetImmediate()` callback was not run or destroyed before the `Environment` destructor started, because that callback held a strong reference to the `Http2Session` object and the expectation was that no such objects exist once the `Environment` constructor starts. Another, slightly more direct, alternative would have been to clear the immediate queue rather than to run it. However, this approach seems to make more sense as code generally assumes that the `SetImmediate()` callback will always run; For example, N-API uses an immediate callback to call buffer finalization callbacks. Unref’ed immediates are skipped, as the expectation is generally that they may not run anyway. Fixes: nodejs#30643 PR-URL: nodejs#30666 Refs: nodejs#30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
pushed a commit
that referenced
this issue
Apr 1, 2020
MylesBorins
pushed a commit
that referenced
this issue
Apr 1, 2020
MylesBorins
pushed a commit
that referenced
this issue
Apr 1, 2020
Guard against running `SetImmediate()` from the destructor. The object will not be alive or usable in the callback, so it does not make sense to attempt to schedule the `SetImmediate()`. Backport-PR-URL: #32301 PR-URL: #30666 Fixes: #30643 Refs: #30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins
pushed a commit
that referenced
this issue
Apr 1, 2020
This can be necessary, because some parts of the Node.js code base perform cleanup operations in the Immediate callbacks, e.g. HTTP/2. This resolves flakiness in an HTTP/2 test that failed when a `SetImmediate()` callback was not run or destroyed before the `Environment` destructor started, because that callback held a strong reference to the `Http2Session` object and the expectation was that no such objects exist once the `Environment` constructor starts. Another, slightly more direct, alternative would have been to clear the immediate queue rather than to run it. However, this approach seems to make more sense as code generally assumes that the `SetImmediate()` callback will always run; For example, N-API uses an immediate callback to call buffer finalization callbacks. Unref’ed immediates are skipped, as the expectation is generally that they may not run anyway. Fixes: #30643 Backport-PR-URL: #32301 PR-URL: #30666 Refs: #30374 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
flaky-test
Issues and PRs related to the tests with unstable failures on the CI.
http2
Issues or PRs related to the http2 subsystem.
worker
Issues and PRs related to Worker support.
Haven't seen this one before. Worth further investigation?
https://ci.nodejs.org/job/node-test-commit-linuxone/17161/nodes=rhel72-s390x/console
test-linuxonecc-rhel72-s390x-2
@nodejs/workers @nodejs/http2 @nodejs/testing
The text was updated successfully, but these errors were encountered: