Bug 696246

Summary: Ghostscript 9.18 with -dFirstPage/-dLastPage fails for ijs and some x11 devices
Product: Ghostscript Reporter: jsmeix
Component: GeneralAssignee: Ken Sharp <ken.sharp>
Status: NOTIFIED FIXED    
Severity: normal CC: andyrtr, chris.liddell, htl10, till.kamppeter
Priority: P4    
Version: master   
Hardware: PC   
OS: Linux   
URL: https://bugs.linuxfoundation.org/show_bug.cgi?id=1324
Customer: Word Size: ---
Attachments: PDF produced by cups-filters

Description jsmeix 2015-10-06 07:16:03 UTC
I submitted this issue about Ghostscript 9.18 for "master"
because there is no "9.18" selectable in the "Version" selection
in Ghostscript bugzilla.

Ghostscript 9.18 with -dFirstPage/-dLastPage fails
for the ijs device and for all or some x11 devices
depending on the input.

Currently the issue is vague for me but I like to report it soon
regardless that currently I do not have a clear reproducer.

I noticed Ghostscript 9.18 failure first when printing with
the HPLIP driver that fails in /var/log/cups/error_log with:
-------------------------------------------------------------------------
Started filter /usr/lib/cups/filter/foomatic-rip
...
Starting renderer with command: gs -dFirstPage=1  -q -dBATCH
 -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs
 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792
 -sDeviceManufacturer="HEWLETT-PACKARD" -sDeviceModel="HP LaserJet 1018"
 -r600 -sIjsParams=Quality:Quality=0,Quality:ColorMode=0,Qual
ity:PenSet=0,PS:MediaPosition=7 -dIjsUseOutputFD -sOutputFile=-
 /var/spool/cups/tmp/foomatic-VQc7ZV
...
renderer received signal 11
-------------------------------------------------------------------------

Because in Ghostscript 9.18 there are changes
regarding -dFirstPage/-dLastPage I started to play around
with that options and noticed that for me the following works
-------------------------------------------------------------------------
# gs -sDEVICE=x11alpha /usr/share/ghostscript/9.18/examples/colorcir.ps

GPL Ghostscript 9.18 (2015-10-05)
Copyright (C) 2015 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusRomNo9L-Reg font from %rom%Resource/Font/NimbusRomNo9L-Reg... 4369956 2769121 3853904 2567303 2 done.
>>showpage, press <return> to continue<<

GS>quit
-------------------------------------------------------------------------

In contrast it fails with -dFirstPage/-dLastPage
-------------------------------------------------------------------------
# gs -dFirstPage=1 -dLastPage=1 -sDEVICE=x11alpha \
 /usr/share/ghostscript/9.18/examples/colorcir.ps

GPL Ghostscript 9.18 (2015-10-05)
Copyright (C) 2015 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /typecheck in --ifelse--
Operand stack:
   --dict:1/2(ro)(G)--   --dict:1/20(L)--   --dict:1/20(L)--   --nostringval--   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nos
tringval--   --nostringval--   false   1   %stopped_push   1967   1   3   %oparray_pop   1966   1   3   %oparray_pop   1950   1
   3   %oparray_pop   1836   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostring
val--   --nostringval--   2   %stopped_push   --nostringval--   %ztokenexec_continue   (scanner state)   --nostringval--
Dictionary stack:
   --dict:1191/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--
Current allocation mode is local
Current file position is 3
GPL Ghostscript 9.18: Unrecoverable error, exit code 1
Unrecoverable error: typecheck in if
Operand stack:
    --nostringval--  --nostringval--
-------------------------------------------------------------------------

Hopefully this is already sufficient for you to reproduce the issue.


I did a test with all devices that "gs -h" reports:
-------------------------------------------------------------------------
# for D in $( gs -h | sed -ne '/alc1900/,/xpswrite/p' ) ; \
 do echo $D ; gs -dFirstPage=1 -dLastPage=1 -dNOPAUSE -dBATCH \
    -dQUIET -sDEVICE=$D -o gs.out \
   /usr/share/ghostscript/9.18/examples/colorcir.ps \
   && echo OK || echo FAIL ; \
 done
-------------------------------------------------------------------------
and got unexpected failures for
  rinki (segfault)
  uniprint
  x11
  x11alpha
while without "-dFirstPage=1 -dLastPage=1" it worked for x11 and x11alpha.
Comment 1 jsmeix 2015-10-06 07:21:09 UTC
Till,
FYI:
see the above mentioned failure with Ghostscript 9.18
when printing with the HPLIP driver (I use hplip-3.15.9).
After downgrading to Ghostscript 9.16 HPLIP 3.15.9 just works.
Comment 2 jsmeix 2015-10-06 07:29:50 UTC
With HPCUPS (that uses the cups device) is also works with Ghostscript 9.18
so that it seems it is realy something with the ijs device.
Comment 3 Ken Sharp 2015-10-06 07:42:39 UTC
(In reply to jsmeix from comment #2)
> With HPCUPS (that uses the cups device) is also works with Ghostscript 9.18
> so that it seems it is realy something with the ijs device.

Various devices had to be modified to work with this new feature, because they did not adhere to the policy of using the standard macros for device initialisation.

I did modify, and smoke test, every device reported by GS under Linux and Windows and all worked (to the extent that they produced output, I wasn't able to actually *test* the output in every case).

Most likely this is simply some extra part of some device(s) which I missed in the initial pass. I will look at it. However, I don't consider it urgent, as this is a new feature and the problem can presumably be avoided by simply not using the new feature ?
Comment 4 Ken Sharp 2015-10-06 07:43:31 UTC
Is this for a 32 or 64 bit build, or both ?
Comment 5 jsmeix 2015-10-06 07:43:58 UTC
Created attachment 11954 [details]
PDF produced by cups-filters

With the attached foomatic-VQc7ZV PDF that is produced
by cups-filters for a plain
# echo hello | lp
I get more failures of x11 devices with "-dFirstPage=1 -dLastPage=1"
namely those x11 devices fail for me:
 x11 x11alpha x11cmyk x11cmyk2 x11cmyk4 x11cmyk8 x11gray2 x11gray4 x11mono
which are all x11 devices that are listed by "gs -h" for me.
Comment 6 jsmeix 2015-10-06 07:46:15 UTC
Currently I run it only on 64 bit.

I could try a 32-bit build on a 64-bit machine but 
it would be a bit hard to run a 32-bit build on a 32-bit machine
because I would need to find a 32-bit machine.
Comment 7 jsmeix 2015-10-06 07:53:36 UTC
Same results with a 32-bit build on a 64-bit machine.
Comment 8 jsmeix 2015-10-06 08:05:52 UTC
Regarding "avoided by simply not using the new feature":

Regarding avoid it in foomatic-rip it seems foomatic-rip
usage of -dFirstPage=1/-dLastPage=1 is compiled into
the foomatic-rip binary according to
--------------------------------------------------------------------------
# strings /usr/lib/cups/filter/foomatic-rip | egrep 'FirstPage|LastPage'
 -dFirstPage=%d -dLastPage=%d 
-dFirstPage=%d
-dLastPage=%d
 -dFirstPage=%d
--------------------------------------------------------------------------

Till,
is it possible to avoid that foomatic-rip uses "-dFirstPage=1"
in its Ghostscript renderer command line when no range of pages
is requested (i.e. when the whole document should be printed)?

Currently I do not know if the foomatic-rip "gs" renderer command line
would work without "-dFirstPage=1" because I do not know how to
disable that.
Comment 9 jsmeix 2015-10-06 08:10:55 UTC
Ken,
it is not urgent because with HPCUPS it also works with Ghostscript 9.18
and furthermore at least for HPLIP their driver that uses ijs (HPIJS)
is deprecated by HPLIP upstream.

FYI:
HP's printer driver software HPLIP contains two drivers:
- the old HPIJS that uses the ijs device and
- the newer HPCUPS that users the cups device.
Comment 10 jsmeix 2015-10-07 03:51:35 UTC
The foomatic-rip "gs" renderer command line does
work without "-dFirstPage=1".

I changed foomatic-rip as described in
https://bugs.linuxfoundation.org/show_bug.cgi?id=1324
which lets foomatic-rip add -dFirstPage=N [and -dLastPage=M]
to the Ghostscript command line only if those options are actually
needed (i.e. if FirstPage > 1 [and when LastPage >= FirstPage]).

Now the foomatic-rip Ghostscript command line is this
---------------------------------------------------------------------------
Starting renderer with command: gs -q -dBATCH -dPARANOIDSAFER -dQUIET
 -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs -dDEVICEWIDTHPOINTS=612
 -dDEVICEHEIGHTPOINTS=792 -sDeviceManufacturer="HEWLETT-PACKARD"
 -sDeviceModel="HP LaserJet 1018" -r600 -sIjsParams=Quality:Quality=0,Qua
lity:ColorMode=0,Quality:PenSet=0,PS:MediaPosition=7 -dIjsUseOutputFD
 -sOutputFile=-   /var/spool/cups/tmp/foomatic-0oesx3
---------------------------------------------------------------------------
and printing with HPIJS works again for me.
Comment 11 Ken Sharp 2015-10-09 02:08:38 UTC
The rinkj device seg faults because there is a required parameter missing in the command line, it needs a 'SetupFile' and if it isn't present there is no protection in the code, it simply dereferences an invalid pointer. So this is not a problem with FirstPgae and LastPage.

The Uniprint device seems to be somewhat similar, the upd_print_page routine rejects the 'showpage' because the 'upd' structure has not been allocated. I'm unable to see where in the code it should be allocated. In any event, the same command line without -dFirstPage and -dLastPage fails in the same way, I don't think this is anything to do with the new code either.

If anyone has a working setup using either of those, and can tell me how to reproduce it, I'll check again.


I don't have an ijs server, which makes it impossible to debug the ijs problem. I did try and set one up but it doesn't work, I have no idea why. I've asked a colleague to try and reproduce this, otherwise I'm afraid I'm not going to be able to look into it.


The problems with x11alpha and x11 are peculiar and seem to be related to DSC processing, so I will investigate those further.
Comment 12 Hin-Tak Leung 2015-10-09 02:57:07 UTC
(In reply to Ken Sharp from comment #11)
...
> I don't have an ijs server, which makes it impossible to debug the ijs
> problem. I did try and set one up but it doesn't work, I have no idea why.
> I've asked a colleague to try and reproduce this, otherwise I'm afraid I'm
> not going to be able to look into it.
...

FWIW, the ijs directory can build a ijs_server_example binary which just converts the ijs data back to simple ps, I think. I may be the last person to have tried building that for windows when I looked at some non-MSVC windows compiler issues with it a while ago. (though support for non-MSVC compilers on the whole had been removed somewhat recently). The ijs_server_example used to work on windows also, the last time I tried it.
Comment 13 Ken Sharp 2015-10-09 03:04:24 UTC
(In reply to Hin-Tak Leung from comment #12)

> compilers on the whole had been removed somewhat recently). The
> ijs_server_example used to work on windows also, the last time I tried it.

I'm using Linux, not Windows.
Comment 14 Chris Liddell (chrisl) 2015-10-09 03:04:39 UTC
The IJS problem is fixed with:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b68e05c3
Comment 15 Hin-Tak Leung 2015-10-09 03:31:47 UTC
(In reply to Ken Sharp from comment #13)
> (In reply to Hin-Tak Leung from comment #12)
> 
> > compilers on the whole had been removed somewhat recently). The
> > ijs_server_example used to work on windows also, the last time I tried it.
> 
> I'm using Linux, not Windows.

Note my "also"... FWIW, for linux, the last time I needed to build the ijs server example, it was just ./autogen.sh, && ./configure && make, in the ijs directory, the usual generic unix way. It has always worked that way, just not built by default, that's all. Building for windows was a bit less straight-forward.
Comment 16 Chris Liddell (chrisl) 2015-10-09 06:13:45 UTC
The x11 problem is fixed with:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=95553954
Comment 17 jsmeix 2015-10-12 03:20:34 UTC
I confirm that the issue is fixed for ijs and the x11* devices.

Many thanks for your prompt upstream fixes!

FYI:
I provide Ghostscript 9.18 with that fixes for various
kind of openSUSE releases via the openSUSE Build Service
development project "Printing" to interested openSUSE users
who like to try out newest printing software on their systems
(cf. https://build.opensuse.org/project/show/Printing).

A side note:
My test with all devices that "gs -h" reports in comment#0
shows segfaults for those devices:
- plibm
- rinkj
Regarding the rinkj device see comment#11.
The plibm segfault is not new now. It also segfauted when
I wrote comment#0. I missed to mention it in comment#0.
I think in general Ghostscript should not segfault.
Comment 18 Ken Sharp 2015-10-12 04:05:18 UTC
(In reply to jsmeix from comment #17)

> A side note:
> My test with all devices that "gs -h" reports in comment#0
> shows segfaults for those devices:
> - plibm
> - rinkj
> Regarding the rinkj device see comment#11.
> The plibm segfault is not new now. It also segfauted when
> I wrote comment#0. I missed to mention it in comment#0.

Hmm, I didn't test that device again. I did test them all (on both Linux and Windows, different device set on each) originally when writing the code and they all 'seemed' to work then, but I wasn't able to test them all sensibly.

Does the plibm device seg fault in the same way on an older version of GS ? I'll try and have a quick look.


> I think in general Ghostscript should not segfault.

I don't disagree, but its not a device (either of them) I have responsibility for, so I'm reluctant to change it.
Comment 19 jsmeix 2015-10-12 04:32:18 UTC
With Ghostscript 9.16 on my SLES12 x86_64 system:
----------------------------------------------------------------------------
# gs -dNOPAUSE -dBATCH -dQUIET -sDEVICE=plibm -o gs.out \
 /usr/share/ghostscript/9.16/examples/colorcir.ps
Segmentation fault

# gs -dNOPAUSE -dBATCH -dQUIET -sDEVICE=rinkj -o gs.out \
 /usr/share/ghostscript/9.16/examples/colorcir.ps
Segmentation fault
----------------------------------------------------------------------------

With Ghostscript 9.15 on my SLES12 x86_64 system:
----------------------------------------------------------------------------
# gs -dNOPAUSE -dBATCH -dQUIET -sDEVICE=rinkj -o gs.out \
 /usr/share/ghostscript/9.15/examples/colorcir.ps
Segmentation fault
----------------------------------------------------------------------------
There is no plibm device in my Ghostscript 9.15.
Comment 20 Ken Sharp 2015-10-12 05:20:30 UTC
(In reply to jsmeix from comment #19)

> ----------------------------------------------------------------------------
> # gs -dNOPAUSE -dBATCH -dQUIET -sDEVICE=plibm -o gs.out \
>  /usr/share/ghostscript/9.16/examples/colorcir.ps
> Segmentation fault

Yep, seems to die for me in the device 'open' routine, it looks like its an allocation problem, but I'm not really familiar with this end of the graphics library.

 
> # gs -dNOPAUSE -dBATCH -dQUIET -sDEVICE=rinkj -o gs.out \
>  /usr/share/ghostscript/9.16/examples/colorcir.ps
> Segmentation fault

See comment #11, this is (clearly) a long-standing flaw in the device.


> There is no plibm device in my Ghostscript 9.15.

That's a little surprising, I see it on Windows since 9.04 and the device was introduced in February 2011 which is consistent with a 9.04 release. In 9.12 it throws an unrecoverable error in .putdeviceprops (must have a BandHeight of at least 200) and in 9.16 and above it seg faults. Note that setting a BandHeight does not get rid of the error message in earlier versions, so this is probably a red herring.....
Comment 21 jsmeix 2015-10-12 05:28:58 UTC
Regarding "no plibm device in my Ghostscript 9.15 ... surprising":

This is how I had built Ghostscript 9.15:
--------------------------------------------------------------------------
./configure --prefix=%{_prefix} \
            --bindir=%{_bindir} \
            --libdir=%{_libdir} \
            --datadir=%{_datadir} \
            --mandir=%{_mandir} \
            --infodir=%{_infodir} \
            --with-fontpath=%{gs_font_path} \
            --with-libiconv=maybe \
            --enable-freetype \
            --with-jbig2dec \
            --without-jasper \
            --enable-openjpeg \
            --enable-dynamic \
            --with-ijs \
            --enable-cups \
            --enable-dbus \
            --with-pdftoraster \
            --with-install-cups \
            --with-drivers=ALL \
            --with-x \
            --disable-gtk \
            --disable-compile-inits \
            --without-omni \
            --without-ufst \
            --without-luratech \
            --without-libpaper
make
--------------------------------------------------------------------------
I guess "--with-drivers=ALL" did not include "plibm".
Comment 22 Ken Sharp 2015-10-12 08:48:06 UTC
I believe this trio of commits:

007bd77d08d800e6b07274d62e3c91be7c4a3f47
1bdbe4f87dc57648821e613ebcc591b84e8b35b3
5571ddfa377c5d7d98f55af40e693814ac287ae4

should address all these remaining problems. 

We now check the SetupFile minimally to at least ensure its been set, which prevents the rinkj crash.

The plib* devices are *supposed* to only work in banding mode, but didn't enforce that. I've added a guard where the crash was occurring (instead of simply assuming that a pointer will be valid) which ensures the crash doesn't occur, and also added code to force banding mode for these devices so that they actually work properly.

Both these changes are minimal, and the I can see ways to provoke the rinkj code into a crash even now. However, its not my area of the code so I'm not going to try and do anything further with the rinkj device.

Note that none of these problems were related to the FirstPage and LastPage code, I probably should have opened a new bug for these but I'm too lazy......