-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
deflateSync
produces binary that inflateSync
fails to decompress
#8886
Comments
You're passing a From the zlib documentation at https://www.zlib.net/manual.html:
Internally, a negative value of |
That then creates a new problem: my original binary is compressed and starts with a |
Also, any idea why |
I was entirely and completely wrong. My apologies. The actual problem is that inflateSync calls zlib like this:
and you'd like to call it with But it's not: the existing code is right for the "raw deflate" format that zlib produces. Per the guidance of the zlib manual, we should default to expecting a zlib header, and assume it is absent only when explicitly told so. But right now, there's no option for that. We could simply check whether there's a valid zlib header, but that would still have many false positives. So, technically, everything is as it should be, except for the function names. Of course there's no way to guess that without improved API documentation. Again, I'm sorry I was wrong. In summary, there are three compressed formats only two of which are known to be disjoint. Both (may) overlap with the third. |
ive found that this affects bun.report's ability to decompress some panic messages, though the in addition to this issue, since Bun 1.1.21, more payloads dont seem to be decompressable:
above:
|
What version of Bun is running?
1.0.26
What platform is your computer?
Microsoft Windows NT 10.0.22631.0 x64
What steps can reproduce the bug?
What is the expected behavior?
A binary compressed with
deflateSync
should always be decompressible withinflateSync
. When using the{ level: 9, windowBits: -15 }
settings, it is not.However it IS decompressible with
gunzipSync
.So we end up with the weird situation in which you have to use
gunzipSync
to decompress anddeflateSync
to compress.What do you see instead?
decompressed
is error: invalid stored block lengthsAdditional information
As per discord discussion, might be related to #8529
Also I ran into: #6401 as well, the docs seem to be incorrect.
The text was updated successfully, but these errors were encountered: