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.

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.

(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 ?

Is this for a 32 or 64 bit build, or both ?

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.

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.

Same results with a 32-bit build on a 64-bit machine.

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.

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.

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.

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.

(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.

(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.

The IJS problem is fixed with:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b68e05c3

(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.

The x11 problem is fixed with:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=95553954

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.

(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.

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.

(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.....

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".

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......