ghostscript segfaulting

[mjcross]

I've been researching today what appears to be the same issue.

I'm using OpenBSD 5.2 release, generic bsd.mp, no patches - plus unmodified release versions of cups, ghostscript-a4-gtk, splix and gstoraster.

Everything was very enigmatic until I decided to run the individual parts of the filter pipeline manually (annoyingly the forum rules mean i cant post urls yet) as per aitch tee tee pee dot fedoraproject.org/wiki/How_to_debug_printing_problems#Running_filters_by_ hand. You can work out the filter pipeline by studying /usr/local/share/cups/mime/mime.conv as per aitch tee tee pee ess discussions.apple.com/thread/2611692?start=0&tstart=0 and you can work out the rasteriser by studying the PPD file for your printer in /etc/cups/ppd.

For a plain text file the pipeline is texttops | pstops | pstoqpdl.

The first two filters run fine (you can view the intermediate results with gs - remember to set the paper size: -sPAPERSIZE=a4 if that's what you're using).

But calling pstoqpdl causes ghostscript to segfault and core dump. Even more interestingly, so does pstoraster (aliased to gstoraster on the release build) - that's significant because gstoraster is nothing to do with splix.

If you google "gstoraster segfault" you will find many links that make it clear this is a problem with the cups raster driver in older versus of ghostscript.

I note that current has an updated version of gs, but I'm not ready to try that yet.

Good luck MC

PS: the correct way to start and stop cups on a modern OBSD system is to do sudo /etc/rc.d/cupsd start (or stop). That will automatically take are of the ulpt ownership things that need to be done :-)

[jggimi]

Your shell's resource limits might be below what ghostscript requires. The default class limits are set very conservatively. The staff class limits are higher, and both the default and staff class limits vary by architecture. The daemon class removes datasize and maxproc limitations:

daemon:\
    :ignorenologin:\
    :datasize=infinity:\
    :maxproc=infinity:\
    :openfiles-cur=128:\
    :stacksize-cur=8M:\ ...

See your /etc/login.conf and the login.conf(5) man page

[mjcross]

Hmm - thanks for the suggestion; I'll have a look at that. But as per the OP I also get the ghostscript segfault when the filters are being run by CUPS, which is (I presume) running as class daemon - so I'm not so sure.

Next step for me will be to transplant some patches to ghostscript 9.05 I think, probably the ones that Til Kampeter has done for Ubuntu.

[ocicat]

Welcome, mjcross!

Your inquiry has been separated from its parent thread because the direction of your questions were different from the original poster.

We find that most members of this site extensively use the archives for mining information. As such, we attempt to keep threads limited to a single topic as directed by the original poster. This is covered in the forum rules.

[mjcross]

actually my post was on the original topic, but maybe that wasn't clear

[jggimi]

Originally Posted by mjcross

...I also get the ghostscript segfault when the filters are being run by CUPS, which is (I presume) running as class daemon...

Yes, the _cups userid is in class daemon. So resource limits are apparently not the root cause.

[mjcross]

Still hacking at this one. Built a clean system from current (snapshot 22jan13) which has ghostscript at 9.06p0, splix at 2.0.0p7 and cups at 1.6.1p5.

Now gs no longer segfaults, but gstoraster is still being obstinate. When I run it manually on the output from pdftops it shows some sensible debug information and tells me the command line with which it's invoking gs, but then hangs perpetually and there's a zombie gs state in the process table.

Digging into the gstoraster.c now but suspect that gs is terminating abnormally in some new and exciting way.

[mjcross]

solved: this was an error in the ghostscript build options (fixed in OpenBSD current)