Description of problem: Printing to a Lexmark inkjet printer under Fedora Core 6, I experience recurring memory leaks with foomatic-rip. A typical example: I am printing a PDF document in Firefox. The print job terminates part way through.foomatic-rip rapidly starts eating up all available memory. If I don't intervene in time, this is what I see in top after several minutes: [...] 2692 lp 18 0 1373m 818m 64 D 5.1 81.1 0:28.86 foomatic-rip [...] (This on a machine with 1GB RAM, 1GB swap.) If I kill gs or foomatic-rip in time, my system returns to normal, otherwise it becomes completely unresponsive and requires a hard reset. I have seen this behavior printing from the above-mentioned Firefox as well as evince. Version-Release number of selected component (if applicable): foomatic-3.0.2-39.1.fc6. The printer is model Lexmark Z51 attached via USB. CUPS is configured to use the lx5000 driver. How reproducible: Everytime I print from Firefox. Steps to Reproduce: 1. print a file from Firefox 2. open "top" in a terminal window 3. observe foomatic-rip engorge itself on all available memory Actual results: If not caught in time, the system chokes. Additional information: I also experienced this problem under FC5.
Can you explain 'The print job terminates part way through' in more detail? Is the job cancelled by the user, or does it fail for some reason, and is there any log message about it, etc?
The print job simply fails part way through, why I don't know. Not a thing in /var/log/messages.
I'd like you to try to reproduce the problem if possible, and to capture the debug logging information while doing so. Here's how (all commands as root): Edit /etc/cups/cupsd.conf and change the 'LogLevel' line to read: LogLevel debug2 Edit /etc/foomatic/filter.conf and add this line at the end: debug: 1 Disable SELinux so that the foomatic log can be written: /usr/sbin/setenforce 0 Stop CUPS: /sbin/service cups stop Clear out the error log file: >/var/log/cups/error_log Start CUPS: /sbin/service cups start Now try to provoke the problem again, and when the job has crashed and (optionally) foomatic-rip has eaten all the memory, I'd like to see: 1. The /var/log/cups/error_log file (you might need to compress it like 'bzip2 -c /var/log/cups/error_log >/tmp/error_log.bz2' first) 2. The /tmp/foomatic-rip.log file 3. The /tmp/foomatic-rip.ps file Thanks.
Created attachment 144751 [details] cups error log
Created attachment 144752 [details] foomatic-rip.ps
Created attachment 144754 [details] foomatic-rip.log
Running this: (gs '-dBATCH' '-dPARANOIDSAFER' '-dQUIET' '-dNOPAUSE' '-sDEVICE=lx5000' '-r600x600' '-dBitsPerPixel=4' '-sOutputFile=/dev/fd/3' '/dev/fd/0' 3>&1 1>&2) <foomatic-rip.ps > /dev/null seems to get stuck in an endless write loop, which would indicate a problem either in the PostScript or in the lx5000 driver. PostScript *looks* fine, so cloning this for ghostscript. Leaving this original bug report for 'why does foomatic-rip buffer it all?'.
Created attachment 144813 [details] Lexmark Z51 ppd requested by someone else
Reported upstream via email.
The "lx5000" GhostScript driver seems to be really broken, even if foomatic-rip would behave correctly, you cannot expect a correct printout. Try the "pbm2l7k" driver. Are you able to print with that one? In this case I will change the recommended driver for the Z51 on linuxprinting.org and mark the "lx5000" driver as obsolete. As long as the printer/driver does not use JCL/PCL (which is the case here) foomatic-rip is not supposed to analyse and buffer the output of GhostScript, it should pass it directly on to standard output. So the behavior is strange. I will look into it.
Seems to be a Perl problem, as cat foomatic-rip.ps | perl -e '$| = 1; pipe R, W; $pid = fork(); if ($pid) {while (<R>) {print $_}} else {open (STDOUT, ">&W"); system "gs -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=lx5000 -r600x600 -sOutputFile=/dev/fd/3 /dev/fd/0 3>&1 1>&2"}' > x eats up all the memory, too. And this command is a simple demonstration how foomatic-rip works. We fork into two processes where one runs GhostScript and another does some post-processing (in this simple example the second process passes the data only to standard output, without actual processing). The data is transported from the first to the second process by a pipe. Or is there something wrong in the use of this method?
(In reply to comment #10) > Try the "pbm2l7k" driver. It doesn't seem to work. I configured the Z51 to use this driver, but when I print, absolutely nothing happens. The print job sits in the Gnome printer queue display marked "Stopped?". I deleted the cups error.log and tried to print again, but nothing was written to it. If there is anything else you want me to try, let me know.
Colin: try enabling the queue with the 'cupsenable' command, or by using the check-box shown in system-config-printer for 'Enabled'. Perhaps the queue is disabled due to the previous driver failing.
Till: here is a version using sysread and syswrite that doesn't seem to grow in memory size. cat foomatic-rip.ps | perl -e '$| = 1; pipe R, W; $pid = fork(); if ($pid){while (sysread(R,$buf,1024)) {syswrite(STDOUT, $buf, length($buf))}} else {open (STDOUT, ">&W"); system "gs -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=lx5000 -r600x600 -sOutputFile=/dev/fd/3 /dev/fd/0 3>&1 1>&2"}' > x
Thank you very much, I will change foomatic-rip appropriately.
(In reply to comment #13) > try enabling the queue with the 'cupsenable' command, or by using the > check-box shown in system-config-printer for 'Enabled'. Perhaps the queue is > disabled due to the previous driver failing. For whatever reason, the pbm2l7k just doesn't work here. Jobs get queued but nothing happens. For the time being I am using the lx5000, albeit very gingerly.
Colin: would you mind filing a separate bug about the pbm2l7k driver? Choose 'ghostscript' as the component. Thanks.
Can you replace your /usr/bin/foomatic-rip file by this one: http://www.linux-foundation.org/~till/tmp/foomatic-rip and then try again to print? Does this solve the problem?
Applied the fix upstream: http://www.linuxprinting.org/download/foomatic/foomatic-filters-3.0-20070220.tar.gz But please test my file posted earlier to see whether this really solves the problem.
I am currently running foomatic-3.0.2-47.2.fc7 and this bug no longer occurs. Thanks!
Great, glad the update fixed it. Thanks for re-testing!