JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression
brian.burkhalter at oracle.com
Thu Jul 13 23:29:47 UTC 2017
On Jul 12, 2017, at 11:52 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 13/07/2017 00:06, Xueming Shen wrote:
>> My reading of the 1.2.11 changes suggests the root cause is that the internal
>> state "deflate_state.high_water" is not being reset correctly/appropriately (to 0?)
>> in deflateReset/deflateResetKeep/lm_init().
>> AND the change of one of the conditions in deflate.c/deflateParams(), from
>> "strm->total_in!=0" to "s->high_water" (in the "Flush last buffer" branch) as showed
>> below, obvious triggers the regression from 1.2.8 to 1.2.11, in the scenario that
>> the "strategy/levle is changed" AND a followup "reset()" is called (with the
>> assumption that everything should be reset back to initial state and we start a
>> new compression circle, with the new level and strategy. This is how it works
>> in 1.2.8 and early releases).
> This is good sleuthing and I think you have identified the regression. The fix looks right although it would be good to get confirmation from the zlib maintainers (no comments on zlib/issues/275 so far).
> As this is a P1 showstopper issue then additional eyes are welcome, esp. if we patch zlib rather than go back to an older version.
I concur with Alan: good detective work figuring this one out. It looks good to me. As a sanity check, on Windows I ran the new version of the DeInflate test without and with the deflate.c change applied and it failed and passed, respectively, as expected.
More information about the core-libs-dev