Hi,
On 8/28/20 1:38 AM, Stephan Bergmann wrote:
All,
The below question came up in the context of a LibreOffice unit test,
where LibreOffice writes out a PNG image (involving zlib for
compression) and the test checked the exact sequence of bytes, which
failed on aarch64 when using Fedora's zlib. (Though the resulting
images look rather identical. Full thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2020-August/085792.html>
"CppunitTest_sw_htmlexport failing due to zlib variation?")
Given the Fedora zlib aarch64 optimization patches quoted below: Does
anybody know whether it is indeed the case that the above scenario
(client code using zlib to generate a PNG image) can legitimately
generate varying output depending on zlib implementation details? Or
would that rather indicate a bug somewhere?
Yes, the short answer is that it is possible to create valid zlib
archives that vary depending on the exact zlib implementation or
compression setting. This is even part of the library's compression
level (Z_BEST_SPEED vs Z_BEST_COMPRESSION) selection.
If one is trying to test a compression function the best way to test it
is to turn around and decompress the output and compare it with the
original rather than checking that the output from a compressor hasn't
changed.
The zlib patches in fedora are an attempt to gain a bit of performance
on an algorithm that compared with more modern algorithm/implementations
is frightfully slow without any significant upside on the compression
ratio. A lot of the byte oriented code runs poorly on modern cores.
Looking at the fedora patches, there appears to be a s390 patch
offloading the whole thing to hardware. This isn't just a arm/s390
problem either as IIRC there were x86 perf fixes posted as well that
haven't been merged either.
Thanks,
Stephan
-------- Forwarded Message --------
Subject: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
Date: Wed, 26 Aug 2020 08:37:15 +0200
From: Stephan Bergmann <sbergman@xxxxxxxxxx>
To: libreoffice@xxxxxxxxxxxxxxxxxxxxx
On 25/08/2020 11:07, Stephan Bergmann wrote:
At least when building recent master on recent Fedora rawhide aarch64
with (among others) --with-system-zlib, CppunitTest_sw_htmlexport
fails with
[...]
The base64-encoded payload apparently is a PNG image. And from what
little I know about PNG, it looks plausible to me that there can be
different (compressed) PNG content that decompress to identical raw
data, and that the LibreOffice code would be allowed to generate
differing (compressed) PNG content for the above data:image/png URL
payload.
What supports the theory that "the LibreOffice code would be allowed to
generate differing (compressed) PNG content" is the Fedora zlib commit
<https://src.fedoraproject.org/rpms/zlib/c/25e9802713484882c27c1f979a6610a42414ee13>
"aarch64 optimizations", adding lots of code that presumably is only
relevant for aarch64 and presumably changes details of the compression
algorithm.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
