Skip to content
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: fix raw inflate with custom dictionary #8512

Closed
wants to merge 2 commits into from

Conversation

thusoy
Copy link
Contributor

@thusoy thusoy commented Sep 13, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

zlib

Description of change

Moves inflateSetDictionary right after inflateInit2 when mode is
INFLATERAW, since without the wrapper in appears zlib won't return
Z_NEED_DICT as it would otherwise, and will thus attempt inflating
without the dictionary, leading to an error.

Closes #8507.

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Sep 13, 2016
case INFLATERAW:
ctx->err_ = inflateInit2(&ctx->strm_, ctx->windowBits_);
ctx->env()->isolate()
->AdjustAmountOfExternalAllocatedMemory(kInflateContextSize);
Copy link
Member

Choose a reason for hiding this comment

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

Just a suggestion, but if you want to avoid duplicating this, you can just turn the break; statement above into if (ctx->mode_ != INFLATERAW) break; and leave the case INFLATERAW: where it is.

Copy link
Member

Choose a reason for hiding this comment

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

Even better: Could this be moved into SetDictionary?

@addaleax addaleax added zlib Issues and PRs related to the zlib subsystem. lts-watch-v4.x labels Sep 13, 2016
@addaleax
Copy link
Member

This looks awesome so far, thanks for putting this together!

@thusoy
Copy link
Contributor Author

thusoy commented Sep 13, 2016

Thanks for the feedback! I'll address the points you raised tonight.

@thusoy
Copy link
Contributor Author

thusoy commented Sep 14, 2016

@addaleax I moved the dictionary initialization into SetDictionary like you suggested as it was much cleaner, thanks! Since the extra test file I added was nearly identical to the existing dictionary test file I fixed the same issues you raised in the new one in the old one as well. Do you think I should merge these two files since they are so similar, or should they be kept separate?

inflate.end();
});

inflate.on('end', function() {
Copy link
Member

Choose a reason for hiding this comment

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

Could you wrap all of these functions which will be called exactly once in a common.mustCall()? (You can do that in test-zlib-dictionary.js too, if you want)

@addaleax
Copy link
Member

Since the extra test file I added was nearly identical to the existing dictionary test file I fixed the same issues you raised in the new one in the old one as well. Do you think I should merge these two files since they are so similar, or should they be kept separate?

That’s your call, if you think it’s easy to merge them together, why not?

This looks good to me (LGTM) with common.mustCall() and a green CI.

Here’s a CI run: https://ci.nodejs.org/job/node-test-commit/5048/

@thusoy
Copy link
Contributor Author

thusoy commented Sep 17, 2016

@addaleax Merged the files and added common.mustCall to the callbacks.

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

deflate.on('data', common.mustCall(function(chunk) {
if (doneReset)
inflate.write(chunk);
}, 2));
Copy link
Member

Choose a reason for hiding this comment

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

I’d say common.mustCall() for data callbacks is optional, I don’t think we’re currently guaranteeing anything about the exact chunking or want to do that (I think this is okay if the CI is green with it included, so it’s your call).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair point, seems like a leaky implementation detail. I removed the mustCalls from non-assertion functions, as if the assertion passes the others are guaranteed to have run, and it will fail if the assertion isn't called.

@thusoy
Copy link
Contributor Author

thusoy commented Sep 19, 2016

Pushed new (final?) changeset without mustCall for non-assertion functions. Thanks for the feedback so far @addaleax.

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

CI: https://ci.nodejs.org/job/node-test-commit/5141/

This looks great, I’ll try to merge this by tomorrow unless somebody else wants to review/objects.

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

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

LGTM

@addaleax
Copy link
Member

Eek, merge conflicts… @thusoy can you rebase this? Apparently one of thea general cleanup PRs of the tests here got in the way of your own cleanup… sorry for that!

Moves inflateSetDictionary right after inflateInit2 when mode is
INFLATERAW, since without the wrapper in appears zlib won't return
Z_NEED_DICT as it would otherwise, and will thus attempt inflating
without the dictionary, leading to an error.

Fixes: nodejs#8507
Uses const where possible, removes inaccurate comments, prefers
strictEqual where possible, ensures functions with assertions are called
and enures the inflater has correct encoding set.
@thusoy
Copy link
Contributor Author

thusoy commented Sep 20, 2016

@addaleax Yup, done.

@addaleax
Copy link
Member

That was fast! Still LGTM.

New CI: https://ci.nodejs.org/job/node-test-commit/5189/

I’m going to land this if it’s green.

addaleax pushed a commit that referenced this pull request Sep 20, 2016
Moves inflateSetDictionary right after inflateInit2 when mode is
INFLATERAW, since without the wrapper in appears zlib won't return
Z_NEED_DICT as it would otherwise, and will thus attempt inflating
without the dictionary, leading to an error.

Fixes: #8507
PR-URL: #8512
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
addaleax pushed a commit that referenced this pull request Sep 20, 2016
Uses const where possible, removes inaccurate comments, prefers
strictEqual where possible, ensures functions with assertions are called
and enures the inflater has correct encoding set.

PR-URL: #8512
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@addaleax
Copy link
Member

Landed in c775514 & 2b5acda. Thank you, this was a great contribution!

@addaleax addaleax closed this Sep 20, 2016
@thusoy thusoy deleted the issue-8507 branch September 20, 2016 21:44
@thusoy
Copy link
Contributor Author

thusoy commented Sep 20, 2016

Great stuff, thanks @addaleax! Happy to contribute!

Fishrock123 pushed a commit that referenced this pull request Oct 11, 2016
Moves inflateSetDictionary right after inflateInit2 when mode is
INFLATERAW, since without the wrapper in appears zlib won't return
Z_NEED_DICT as it would otherwise, and will thus attempt inflating
without the dictionary, leading to an error.

Fixes: #8507
PR-URL: #8512
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Fishrock123 pushed a commit that referenced this pull request Oct 11, 2016
Uses const where possible, removes inaccurate comments, prefers
strictEqual where possible, ensures functions with assertions are called
and enures the inflater has correct encoding set.

PR-URL: #8512
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins
Copy link
Contributor

backport?

@addaleax
Copy link
Member

@thealphanerd If that is a yes/no question, yes. :)

@thusoy Would you be up for backporting this change to the v4.x release line? There are some conflicts in the test files that seem to need resolving.

The usual process for that would be checking out the v4.x-staging branch here and cherry-picking the commits as they landed on master (only c775514 should suffice), then resolving any conflicts and PRing with the staging branch as the base branch. I or somebody else can do that too, but I’m a bit busy at the moment and you clearly did a good job here in the first place.

@thusoy
Copy link
Contributor Author

thusoy commented Oct 24, 2016

@addaleax Thanks for the heads-up on the process. I might be able to that, but will probably be a couple of days before I have time. Consider me on the case for now.

easyaspi314 added a commit to easyaspi314/pako that referenced this pull request Nov 13, 2017
This is just roughly tested, but I just ported the
change from nodejs/node#8512, or at least attempted to.

Before, when trying to inflateRaw (or inflate({raw:true});) with a custom
dictionary, you would get 'invalid distance too far back'.

This no longer seems to happen, so I think I fixed it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. zlib Issues and PRs related to the zlib subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

zlib: invalid distance too far back on inflateRaw with custom dictionary
5 participants