Dear Maintainer,

the problem starts with upgrading from 'stretch' to 'buster'.
Printer doesn't print properly.

After downgrade ghostscript, libgs9 and libgs9-common to the version from oldstable ('stretch'), printer works properly again.

reassign 942055 ghostscript
severity 942055 important
found 942055 9.27~dfsg-2+deb10u1
thanks


Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
     I upgraded my server running on armel from stretch to buster. Since
     then I was unable to print pictures via my cups server installed on
     the armel system.
   * What exactly did you do (or not do) that was effective (or
   * What was the outcome of this action?
     ineffective)?
     Printing the cups test page results in just the test being printed,
     not the images. Same for other documents.
   * What outcome did you expect instead?
     Testpage should print with images :)

*** End of the template - remove these template lines ***

After the upgrade from stretch to buster, I noticed that I can't images
anymore. When printing pages with images, the part of the page is
usually left empty.  Same problem with text containing special
characters.

Installing cups on my amd64 notebook, I can print without problems
anymore, so it doesn't seem to be a general problem.

Downgrading the ghostscript pagages to the version in Debian 9 solved my
issues.


Please feel free to contact me for futher tests or debugg output.  I
grant that this issue might not be easy to reproduce ;)


Best regards,
  Alexander

reassign 942055 ghostscript
severity 942055 important
found 942055 9.27~dfsg-2+deb10u1
thanks


Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
     I upgraded my server running on armel from stretch to buster. Since
     then I was unable to print pictures via my cups server installed on
     the armel system.
   * What exactly did you do (or not do) that was effective (or
   * What was the outcome of this action?
     ineffective)?
     Printing the cups test page results in just the test being printed,
     not the images. Same for other documents.
   * What outcome did you expect instead?
     Testpage should print with images :)

*** End of the template - remove these template lines ***

After the upgrade from stretch to buster, I noticed that I can't images
anymore. When printing pages with images, the part of the page is
usually left empty.  Same problem with text containing special
characters.

Installing cups on my amd64 notebook, I can print without problems
anymore, so it doesn't seem to be a general problem.

Downgrading the ghostscript pagages to the version in Debian 9 solved my
issues.


Please feel free to contact me for futher tests or debugg output.  I
grant that this issue might not be easy to reproduce ;)


Best regards,
  Alexander

notfound 942055 9.26a~dfsg-0+deb9u5
thanks

Version in oldstable is not affected by this regression.

Hello Michael, hello Alexander,
as I have such an armv5tel device I tried if I
could get some more information.

I setup a printer like in the subject from message 5
and set the output to a port that I redirected to a file.
This showed for armv5tel a smaller file than for amd64.

Also it showed an error message that seems to
come from gostscripts gs_ttf.ps:

    $ hexdump -C testprint-amd64 | head -n5
    00000000  1b 25 2d 31 32 33 34 35  58 40 50 4a 4c 20 0d 0a  |.%-12345X@PJL ..|
    00000010  40 50 4a 4c 20 4a 4f 42  20 4e 41 4d 45 3d 22 47  |@PJL JOB NAME="G|
    00000020  68 6f 73 74 22 0d 0a 40  50 4a 4c 20 53 45 54 20  |host"..@PJL SET |
    00000030  45 43 4f 4e 4f 4d 4f 44  45 3d 4f 46 46 0a 40 50  |ECONOMODE=OFF.@P|
    00000040  4a 4c 20 53 45 54 20 4d  45 44 49 41 54 59 50 45  |JL SET MEDIATYPE|

    $ hexdump -C testprint-armel | head -n5
    00000000  43 61 6e 27 74 20 68 61  6e 64 6c 65 20 66 6f 72  |Can't handle for|  <<<
    00000010  6d 61 74 20 34 0a 1b 25  2d 31 32 33 34 35 58 40  |mat 4..%-12345X@|
    00000020  50 4a 4c 20 0d 0a 40 50  4a 4c 20 4a 4f 42 20 4e  |PJL ..@PJL JOB N|
    00000030  41 4d 45 3d 22 47 68 6f  73 74 22 0d 0a 40 50 4a  |AME="Ghost"..@PJ|
    00000040  4c 20 53 45 54 20 45 43  4f 4e 4f 4d 4f 44 45 3d  |L SET ECONOMODE=|

https://sources.debian.org/src/ghostscript/9.27%7Edfsg-2+deb10u3/Resource/Init/gs_ttf.ps/#L506

In an attempt to follow the filter down I got this gs command
that produces the same error message for attached input PDF:

    # uname -a
    Linux qnap119 4.19.0-6-marvell #1 Debian 4.19.67-2+deb10u2 (2019-11-11) armv5tel GNU/Linux
    # gs -dShowAcroForm  -q -dBATCH -dPARANOIDSAFER -dNOPAUSE -dNOMEDIAATTRS -dNOINTERPOLATE -sDEVICE=hl1250 -dEconoMode=0 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r300x300 -dSourceTray=0 -dPaperType=0 -sOutputFile=- -f   /tmp/tmp/foomatic-9RyCd0
    Can't handle format 4
    12345X@PJL
    @PJL JOB NAME="Ghost"
    ...

The same inputfile with the same command gives on amd64 no such error.

Maybe you can confirm that this errormessage is contained in the data
sent to your printers too.

An attempt to run the command with -dDEBUG led to a crash that does also
just show up on armel/armv5tel, but not in amd64 and not in armel/armv7l.

Kind regards,
Bernhard

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.26a~dfsg-2
Control: found -1 9.26a~dfsg-1
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


Hello,
tried to get a little further.

The last version from sid that did not show this error
was 9.22~dfsg-1. All other good version seem to be created
as security updates, where I cannot find the build logs.

Kind regards,
Bernhard

Hi!

Am 2020-02-04 22:09, schrieb Jonas Smedegaard:

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?

I'm open for suggestion on how to continue next, but have honestly. If I
should fill a bug against an other package, please let me know which
one, as I have no idea, how these parts are interacting with each other.


Best regards,
   Alexnader

reassign 942055 cups-filters
thanks

Hi Jonas!


* Jonas Smedegaard <jonas@jones.dk> [200205 11:02]:

Seems ressonable, thanks for the hint and your work!


Best regards,
  Alexander

Hello Jonas,
thanks for taking time for this bug.


Am 05.02.20 um 11:02 schrieb Jonas Smedegaard:


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

[ sent again to please Debian MTAs rejecting 8bit headers ]

control: tag -1 wontfix

Quoting Bernhard Übelacker (2020-02-04 20:13:41)
degree in security updates - was a security fix affecting interpretation
of Postscript code.

Yes, it broke existing working code, but (as I
understand it) only existing _insecurely_ working code.

The change is highly unlikely to get reverted: Instead, reverse
dependencies of Ghostscript need to apply fixes to tighten their code to
avoid those Postscript routines identified as being insecure and
therefore no longer permitted (or if certain that security is ensured in
other ways then explicitly disable the safety measures).

Please do not reassign these bugs to Ghostscript, even though provable
that they are "fixed" by downgrading Ghostscript.  The fix needs to be
applied at the consumer end.


 - Jonas

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)

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!)

Yes, got it. Thanks!

Yes. Got it.  Will try on an armel box I got...

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

Dear submitter,

Can you advise whether this is still an issue?  I ran the attached foomatic
file through gs on amd64 and it still works fine.  But I have no access to an
armel machine.

Thanks,
-Steve

Dear submitter,

Can you advise whether this is still an issue?  I ran the attached foomatic
file through gs on amd64 and it still works fine.  But I have no access to an
armel machine.

Thanks,
-Steve