Skip to content

zlib: do not leak on destroy #23734

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.

Sign up for GitHub

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

Closed
mafintosh wants to merge 4 commits into from
Closed

zlib: do not leak on destroy #23734

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f1055e3
zlib: do not leak on destroy
mafintosh Oct 18, 2018
91cdb3d
add @mcollina's test case
mafintosh Oct 22, 2018
9f7b2ce
add close in ondata test
mafintosh Oct 22, 2018
6a34ccd
use Buffer.alloc instead of allocUnsafe
mafintosh Oct 23, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
zlib: do not leak on destroy
  • Loading branch information
@mafintosh
mafintosh committed Oct 18, 2018
commit f1055e38aa5c6eb18150a031d58c92cb75dd67e3
9 changes: 9 additions & 0 deletions lib/zlib.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -430,6 +430,11 @@ Zlib.prototype.close = function close(callback) {
this.destroy();
};

Zlib.prototype._destroy = function _destroy(err, callback) {
_close(this);
callback(err);
Comment thread
mcollina marked this conversation as resolved.
};
Comment thread
addaleax marked this conversation as resolved.

Zlib.prototype._transform = function _transform(chunk, encoding, cb) {
var flushFlag = this._defaultFlushFlag;
// We use a 'fake' zero-length chunk to carry information about flushes from
Expand Down Expand Up @@ -592,6 +597,10 @@ function processCallback() {
assert(false, 'have should not go down');
}

if (self.destroyed) {
Copy link
Copy Markdown
Member

@lpinca lpinca Oct 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already a check for this a few line above, isn't that one sufficient?

Copy link
Copy Markdown
Member

@addaleax addaleax Oct 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the idea is that the push() call can trigger on('data') listeners which can destroy the stream?

Either way, it would be great to have a test for this (and the other bits in this PR)

Copy link
Copy Markdown
Member

@lpinca lpinca Oct 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, makes sense, I think a comment would also help.

Copy link
Copy Markdown
Member Author

@mafintosh mafintosh Oct 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually already tested as the existing tests fail (crash even!) without this.

return;
}

// exhausted the output buffer, or used all the input create a new one.
if (availOutAfter === 0 || self._outOffset >= self._chunkSize) {
handle.availOutBefore = self._chunkSize;
Expand Down