On Jul 12, 2017, at 11:52 PM, Alan Bateman <alan.bate...@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. Brian
