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
