-
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
Zlib InflateRaw null reference #6034
Comments
Looks like it's already being fixed: #5982 |
ChALkeR
added
duplicate
Issues and PRs that are duplicates of other issues or PRs.
zlib
Issues and PRs related to the zlib subsystem.
labels
Apr 4, 2016
4 tasks
3 tasks
addaleax
added a commit
to addaleax/node
that referenced
this issue
Apr 19, 2016
Add a regression test based on the report in nodejs#6034.
joelostrowski
pushed a commit
to joelostrowski/node
that referenced
this issue
Apr 25, 2016
An internal zlib error may cause _handle to be set to null. Close now will check if there is a _handle prior to calling .close on it. PR-URL: nodejs#5982 Fixes: nodejs#6034 Reviewed-By: Brian White <mscdex@mscdex.net> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
joelostrowski
pushed a commit
to joelostrowski/node
that referenced
this issue
Apr 25, 2016
Add a regression test based on the report in nodejs#6034. PR-URL: nodejs#6270 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax
added a commit
to addaleax/node
that referenced
this issue
May 4, 2016
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like nodejs#6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error.
addaleax
added a commit
that referenced
this issue
May 17, 2016
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Fishrock123
pushed a commit
that referenced
this issue
May 23, 2016
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
rvagg
pushed a commit
that referenced
this issue
Jun 2, 2016
This is purely cleanup and carries no visible behavioural changes. Up to now, `this._closed` was used in zlib.js as a synonym of `!this._handle`. This change makes this connection explicit and removes the `_closed` property from zlib streams, as the previous duplication has been the cause of subtle errors like #6034. This also makes zlib errors lead to an explicit `_close()` call rather than waiting for garbage collection to clean up the handle, thus returning memory resources earlier in the case of an error. Add a getter for `_closed` so that the property remains accessible by legacy code. PR-URL: #6574 Reviewed-By: Colin Ihrig <cjihrig@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
Zlib references a null object on close after an error:
Output:
See websockets/ws#664
The text was updated successfully, but these errors were encountered: