ghostscript take all memory

[Skeletonix]

Binary package hint: ghostscript

If I want print (Epson Stylus C64) in BEST quality system freeze and the process:

/usr/bin/gs -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=CUPS -sstdout=%stderr -sOUTPUTFILE=%stdout -C -

takes all available memory (900Mb RAM + SWAP). The owner of process is user: LP .

When is set print quality to lower then BEST (for example SUPER PHOTO, NORMAL ...) everything work properly.

----
Gutsy Gibbon [amd64]

[Martin G Miller (mgmiller)]

This may be related to my bug 157044. I have found in photoprinting, ghostscript (gs) takes 99% of cpu and the document stays in the print que for over 60 seconds. This does not happen when printing plain text, which prints almost instantly.

[glepore70 (greg-rhobard)]

Confirming this bug (or #157044) on 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
Epson PictureMate takes over 15 minutes to print a single 4x6 photo. htop shows lp and gs taking all of both cores of my Athlon dual core 4200+, plus a gig of RAM, plus all my swap.
I haven't tried changing the print quality to less than Best.

[Martin G Miller (mgmiller)]

I have my print quality set to 2 out of 4, With 4 being the best. 2 is only 600 dpi and I still have over 60 seconds in print que for a 4x6 photo print. It sounds like glepore70 has the cups bug also, since lp is using a lot of resources. Take a look at bug 157044 for instructions on how to work around the lp part of your problem. Unfortunately, the gs bug continues.....

[Daniel T Chen (crimsun)]

Is this symptom still reproducible in 8.10?

[glepore70 (greg-rhobard)]

I'm running Kubuntu Intrepid and I just encountered this bug while attempting to print 20 pages in a PDF file. The gs process took all available memory, plus swap, plus CPU, eventually getting killed by the system after 20 minutes or so.
Linux upstairs 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
If anyone has debugging steps that I can take, I am willing to help try and fix this. Printing individual pages from the PDF worked fine, printing 5 pages at a time worked well but took close to 10 minutes, printing 20 pages didn't work. This is with a Dell 1110 printer. I had this bug earlier with an Epson PictureMate. Printing pictures to the PictureMate now works properly; probably due to the two different bugs (this one and 157044.)

[Martin G Miller (mgmiller)]

I have upgraded from Hardy to Intrepid (8.10). I have also upgraded my hardware to an AMD triple core CPU, 3 1/2 gig of ram, SATA II HDD, etc. 4x6 photo prints still sit in que for 40 seconds with gs using 85% CPU. At least I have enough horsepower now that I can do other things while I wait for the print que to process.

[Paul Broadhead (pjbroad)]

I've just installed Ubuntu 8.10 on my main desktop (previously using Debian for more years than I can remember). I'm now encountering this bug too. I have a HP deskjet 5150 (identified as a 5100). My wife does a lot of photo printing so I may have to revert! Is there anything more I/we can add to this bug report to help get it resolved?

Other information is that during this big memory/cpu hogging delay/freeze, the printing system switches to thinking the printer is not connected. Also strace shows that the gs process is busy doing write() calls with different content. The gs command line is:

gs -dFirstPage=1 -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -sDeviceManufacturer=HEWLETT-PACKARD -sDeviceModel=deskjet 5600 -dDuplex=false -r1200 -sIjsParams=Quality:Quality=3,Quality:ColorMode=2,Quality:MediaType=2,Quality:PenSet=2,Quality:FullBleed=1,PS:MediaPosition=7 -dIjsUseOutputFD -sOutputFile=- /var/spool/cups/tmp/foomatic-w0KijW

I notice that the DeviceModel is incorrect so I'll investigate that further.

From Debian lenny, everything works fine and fast, printing using the same printer, computer, image and app (gimp).

[Paul Broadhead (pjbroad)]

A little bit more information. I tried the suggestion in bug 157044 but that did not help.

I found the following entry in various log files (/var/log/messages here):

Jan 1 18:58:56 ron kernel: [ 9959.511563] type=1503 audit(1230836336.521:16): operation="inode_permission" requested_mask="::rw" denied_mask="::rw" fsuid=7 name="/dev/tty" pid=15522 profile="/usr/sbin/cupsd"
Jan 1 18:58:56 ron hpijs: warning setting paper size=1, err=-30

This error occurs every time I try to print the image. I'm using gimp, the error occurs after the gimp processing and just as the entry appears in the print queue. I have checked every option I can find in my settings and they appear to be correctly specifying the page size.

[Paul Broadhead (pjbroad)]

I found a fix for this problem.

I searched for the "warning setting paper size" error and found Bug #288570 which appears related. This bug has been fixed in a new version of ghostscript which is currently in the intrepid-proposed area. I followed the instructions to install the intrepid-proposed version and the bug appears fixed.