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 via email to