On Wed, Jul 22, 2020 at 06:38:50PM -0400, Tom Lane wrote:
> is setting next_in to garbage. However, if we've already set
> eof to 1, which we have, then we won't call inflate() again
> so the garbage pointer should not matter. (Besides which,
> zlib really shouldn't dereference that pointer if avail_in is 0.)
Yeah, I looked at zlib quite a bit to reach this same conclusion when
studying this problem.
> I'm still baffled as to why only the SLES s390x animals are failing,
> but it's beginning to seem like it might be due to them using a
> different zlib version.
My main suspicion is that they are using hardware-specific calls in a
proprietary fork of libz. They have a lot of changes in their
release notes that are hardware-specific:
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP1/
I could not find the RPMs though, and perhaps it is based on zlib-ng
or similar but that's hard to say.
> Horiguchi-san's v3 patch at
> <20200612.145412.475791851624925277.horikyota.ntt@gmail.com>
> doesn't have either of these problems, so it seems much superior
> to me than what you actually did. I don't have a lot of hope that
> changing to that one would fix the buildfarm problem --- but maybe it
> would, if the machine-dependent behavior is somehow hiding in the
> repeat-call-after-EOF code path.
Perhaps. It could be possible to give it a try on HEAD, though I
doubt that it would solve the problem :/
For now, more investigation is needed for this SLES behavior though.
So, to put the buildfarm back to green, I am reverting the patch.
--
Michael