Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 17850 [details]
Working windows console app and Xamarin iOS app with premature end of stream
When decompressing certain compressed files, reading the DeflateStream byte-by-byte with ReadByte() will omit the last few bytes, seemingly hitting end-of-stream prematurely.
On the same file, using DeflateStream.CopyTo(otherStream) copies the data correctly.
(I've also encountered a problem with EndOfStreamException when trying to use a BinaryReader on the DeflateStream for the same files.)
I'm not sure why only certain files cause it or what the pattern is in the failing files.
In the attached zip are solutions for a Xamarin iOS app and a Windows Console App.
Each has two compressed file resources that they attempt to decompress: "compressed.bin" and "compressed2.bin".
The decompressed size is calculated for each, both via CopyTo into a MemoryStream, and by reading to the end with ReadByte().
The only incorrect case is when reading "compressed.bin" with ReadByte on iOS, which yields 125377 bytes instead of 125387 bytes.
Using ReadByte on Windows or using CopyTo will yield the correct deflated size for the first file.
The other file "compressed2.bin" decompresses correctly on both platforms with both approaches.
I discovered that appending some zero-value bytes to the end of the file will fix every case of the issue I've seen.
Doing that as a workaround shouldn't cause any other output problems with the Deflate algorithm, should it?
(My knowledge of the Deflate specification is that it works on a block-by-block basis and that each block has an "is last block" header bit, so I don't expect superfluous bytes in input to cause extra bytes on output or anything like that.)
As a temporary workaround (and depending on ETA for a real fix), I might create a read-only Stream wrapper that appends a small number of superfluous bytes to the end of the wrapped FileStream (without actually modifying the file).
I actually discovered one particular (very small) compressed file also has incorrect results even with CopyTo:
The correct decompressed length should be 81942 bytes according to windows.
The decompressed length when using CopyTo on iOS is 81921.
The decompressed length when reading byte-by-byte on iOS is 81697.
This might be related to bug #34916.
@joao could you merge it to Mono 4.8 as well