Gzip decompress Unexpected EOF with small buffer + fix

[hhblaze]

Steps to reproduce

1. Gziped 38KB file

2. Trying to ungzip it supplying into GZipInputStream.Read buffer with the size 10KB (smaller than gzipped array itself). Receive "Unexpected EOF".

3. If to use buffer 50KB (more than gzipped array) - all works.

4. It started to work with smaller buffer when the part in GZipInputStream.Read was remarked:
   

5. Code for decompressing

public static byte[] Decompress(this byte[] data)
{
    if (data == null)
        return null;
                
    byte[] unzipped = new byte[10000];
    int readOut = 0;
    byte[] res = null;

    try
    {
        using (Stream stream = new GZipInputStream(new MemoryStream(data)))
        {
            using (MemoryStream memory = new MemoryStream())
            {
                while((readOut = stream.Read(unzipped, 0, unzipped.Length))>0)
                    memory.Write(unzipped, 0, readOut);   

                res = memory.ToArray();
                memory.Close();
            }
            stream.Close();
        }
    }
    catch
    {   
        res = null;
    }
    return res;
}

Expected behavior

Unzip

Actual behavior

Unexpected EOF

Version of SharpZipLib

Obtained from (only keep the relevant lines)

• Compiled from source, commit: 6f245b3

[Numpsy]

It looks like the ReadWriteThroughtput GZip unit test fails with the same exception (that test is marked as explicit, so it isn't run by default).

Looks like that throw was only added in a35ce40, don't know if removing it reverts part of that fix.

[piksel]

Yeah, this needs to be resolved before 1.2, something is clearly not behaving as expected. Why would a smaller buffer make that condition return false?

[Numpsy]

Possibly it's incorrectly throwing in cases where the inflator has used up its own internal buffer, but the input stream still has data left? (maybe it should only be doing that check if bytesRead is 0?)

[piksel]

Yes, that could be it. Due to confusion about what inf.RemainingInput refers to...

[Numpsy]

Changing it to throw if inf.RemainingInput and bytesRead are both 0 fixes the test failure (e.g.

else if (inf.RemainingInput == 0 && bytesRead == 0)

Not certain if that is the right fix though (I hadn't previously realised that it explicitly tries to not throw in cases where there is garbage in the stream after the end of the valid data).

[piksel]

Okay, I finally know whats going on! I was wrong, see #372 for the real solution.

There is no more Input to read, since all the bytes have been read, but no more bytes will be written to the output buffer since it's full. So a simple fix would be to check if the buffer is full (bytesRead == count). If the buffer sizes exactly matches up with the needed bytes I think the next read should be 0 bytesRead, but some more testing is needed.