Bug#942055: ghostscript in buster partly broken on armel?
Hello Jonas,
thanks for taking time for this bug.
Am 05.02.20 um 11:02 schrieb Jonas Smedegaard:
> Hi Alexander,
>
> Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05)
>> Am 2020-02-04 22:09, schrieb Jonas Smedegaard:
>>
>>> Most notable change between 9.22 and 9.24 - and also applied to
>>> various degree in security updates - was a security fix affecting
>>> interpretation of Postscript code.
>>
>> Maybe a stupid question, but does that fix work? I'm just wondering,
>> if the firx triggers a problem on one arm but not on amd64, is it
>> working?
>
> Fair question.
>
> Ghostscript is (mainly) a Postscript interpreter.
>
> To investigate if the cause for this issue is a) Ghostscript
> _interpreting_ differently on arm than on amd64, or a tool further back
> in the chain _producing_ different code for Ghostscript to interpret, it
> seems to me that we need someone to isolate the actual code fed into
> Ghostscript.
>
> I maintain the Ghostscript package, but am not skilled in the various
> tools using Ghostscript. It seems more sensible to me to first
> investigate toolchain problems further back in the chain, where (I
> assume) it is better known how to isolate the data forwarded down the
> chain.
I guess this is what I did in previous message 33 ?
There I attached file foomatic-9RyCd0 which is fed by cups into ghostscript.
I have put the ghostscript command line parameter also in message 33.
This file, seems to be just a PDF,
is interpreted by ghostscript at amd64 without issue.
But gives the message "Can't handle format 4" at an armv5tel/armel
(real hardware, QNAP, Feroceon 88FR131).
And even worse it might manifests just on armv5tel/armel,
in my qemu armv7/armel VM it works without problems too.
Therefore I guess you are right and this is not an issue of
ghostscript, but could be compiler related.
I continued testing and a package "9.25~dfsg-7" compiled
in an unstable chroot as of date 2017-12-07 produces a working package.
But a package "9.25~dfsg-7" built inside a unstable chroot as of
date 2018-01-01 crashes in gx_filter_edgebuffer, like current
version in buster 9.27~dfsg-2+deb10u3 with "-dDEBUG" set.
Therefore I guess this could be related to the switch from
gcc-7 7.2.0-16 to gcc-7 7.2.0-18 in that time frame.
(The -18 raised the baseline to armv5te.)
That would at least explain why the stretch stable update
packages do not show the problem (e.g. 9.26a~dfsg-0+deb9u6),
as they should be built with stretch's gcc-6.
But without pointing to an exact instruction or function I
cannot prove it. So are there any hints how to
further debug ghostscript in that regard?
Kind regards,
Bernhard
Reply to: