control: reassign -1 ghostscript Control: fixed -1 9.26a~dfsg-0+deb9u6 Control: fixed -1 9.26a~dfsg-0+deb9u1 Control: fixed -1 9.25~dfsg-0+deb9u1 Control: found -1 9.27~dfsg-3.1 Control: found -1 9.27~dfsg-3 control: found -1 9.27~dfsg-2+deb10u3 control: found -1 9.27~dfsg-2+deb10u1 Control: found -1 9.26a~dfsg-2 Control: found -1 9.26a~dfsg-1 control: fixed -1 9.26a~dfsg-0+deb9u5 Control: found -1 9.26~dfsg-2 Control: found -1 9.26~dfsg-1 Control: found -1 9.25~dfsg-7 Control: found -1 9.25~dfsg-2 Control: found -1 9.24~~rc2~dfsg-1 Control: fixed -1 9.22~dfsg-1 Control: fixed -1 9.21~dfsg-1 Control: fixed -1 9.20~dfsg-3.2 [ sent again to please Debian MTAs rejecting 8bit headers ] Hi Bernhard, Quoting Bernhard Übelacker (2020-02-05 15:06:02) > 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 ? Ohh, indeed! Great details and smells strongly of the bug being in Ghostscript. I am hereby re-re-re-assigning and reviving versions... (weird - I received your later emails fine but that one crucial message is not in by mailsystem - I must've simply hit the wrong key when processing it, sorry!) > There I attached file foomatic-9RyCd0 which is fed by cups into > ghostscript. Yes, got it. Thanks! > I have put the ghostscript command line parameter also in message 33. Yes. Got it. Will try on an armel box I got... > 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? Might be helpful if you could provide the stdout and stderr outputs of _only_ running the Ghostscript command - executed on amd64 and armel for easy comparison. Also might be helpful to do the same passing additional option -dTTFDEBUG (as that seems to show more detail in the aread where it seems to fail). ...or if some of above is already covered in your previously provided debugging.txt then if you could help point exactly where... I say "might" above because really this is more geeky than I can handle myself, so I am just guessing what upstream might find helpful - in other words: it would be even more helpful if (above more narrow test still fails then) you would file this directly as a bugreport upstream at https://bugs.ghostscript.com/ as it sounds like you would be better at guiding them than I am. Kind regards, and sorry for missing that crucial previous post, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature