RFR: 8292327: java.io.EOFException in InflaterInputStream after JDK-8281962

[Volker Simonis]

On Mon, 15 Aug 2022 18:34:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The problem is that after [JDK-8281962](https://bugs.openjdk.org/browse/JDK-8292327) we call `fill()` unconditionally (and before calling `Inflater::inflate()`) in `InflaterInputStream::read()` if `Inflater::needsInput()` is true. This misses the case where the native inflater has consumed all its input (i.e. `Inflater::needsInput()` returns true) but hasn't managed to write all the inflated data into the output buffer (e.g. because it was to small). In rare cases, there might be now more input available (i.e. calling `InflaterInputStream::fill()` will throw an `EOFException`) but we still have to call `Inflater::inflate()` to consume the buffered output from the underlying native inflater until inflation stops. 
>> 
>> The documentation of the `inflate()` method in `zlib.h` mentions this explicitely:
>> 
>>> "If `inflate()` returns `Z_OK` and with zero `avail_out`, it must be called again after making room in the output buffer because there might be more output pending."
>
> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 161:
> 
>> 159:                     // Even if needsInput() is true, the native inflater may have some
>> 160:                     // buffered data which couldn't fit in to the output buffer during the
>> 161:                     // last call to inflate. Consume that bffered data first before calling
> 
> bffered -> buffered

Fixed.

> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 164:
> 
>> 162:                     // fill() to avoid an EOF error if no more input is available and the
>> 163:                     // next call to inflate will finish the inflation.
>> 164:                     fill();
> 
> We need to submit a bug against fill() too as it is not currently specified to throw when the input is at EOF.

Not sure about this one? `fill()` is specified to throw an `IOException` and `EOFException` is an `IOException`. It probably depends on how you interpret the current "*if an I/O error has occurred*" description in the throws section.

Do you propose to be more specific there and write something like "*if an I/O error has occurred or the end of the input buffer has been reached*"?

-------------

PR: https://git.openjdk.org/jdk/pull/9881