Bug 221194 - foomatic-rip memleak
Summary: foomatic-rip memleak
Alias: None
Product: Fedora
Classification: Fedora
Component: foomatic (Show other bugs)
(Show other bugs)
Version: 6
Hardware: i386 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
Blocks: FC6Update 221418
TreeView+ depends on / blocked
Reported: 2007-01-02 21:20 UTC by Colin Brace
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 3.0.2-47.2.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-24 14:47:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cups error log (21.29 KB, application/octet-stream)
2007-01-03 23:26 UTC, Colin Brace
no flags Details
foomatic-rip.ps (39.40 KB, application/octet-stream)
2007-01-03 23:27 UTC, Colin Brace
no flags Details
foomatic-rip.log (2.50 KB, text/plain)
2007-01-03 23:31 UTC, Colin Brace
no flags Details
Lexmark Z51 ppd (15.23 KB, text/plain)
2007-01-04 16:12 UTC, Colin Brace
no flags Details

Description Colin Brace 2007-01-02 21:20:58 UTC
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

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

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.

Comment 1 Tim Waugh 2007-01-03 16:41:17 UTC
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?

Comment 2 Colin Brace 2007-01-03 18:56:01 UTC
The print job simply fails part way through, why I don't know.

Not a thing in /var/log/messages.

Comment 3 Tim Waugh 2007-01-03 21:18:27 UTC
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:


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


Comment 4 Colin Brace 2007-01-03 23:26:50 UTC
Created attachment 144751 [details]
cups error log

Comment 5 Colin Brace 2007-01-03 23:27:54 UTC
Created attachment 144752 [details]

Comment 6 Colin Brace 2007-01-03 23:31:26 UTC
Created attachment 144754 [details]

Comment 7 Tim Waugh 2007-01-04 16:00:21 UTC
Running this:

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

Comment 8 Colin Brace 2007-01-04 16:12:13 UTC
Created attachment 144813 [details]
Lexmark Z51 ppd

requested by someone else

Comment 9 Tim Waugh 2007-01-04 16:33:30 UTC
Reported upstream via email.

Comment 10 Till Kamppeter 2007-01-05 17:24:32 UTC
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.

Comment 11 Till Kamppeter 2007-01-05 22:56:02 UTC
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
-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?

Comment 12 Colin Brace 2007-01-07 01:33:40 UTC
(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.

Comment 13 Tim Waugh 2007-01-08 17:33:53 UTC
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.

Comment 14 Tim Waugh 2007-01-08 17:40:38 UTC
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
-sDEVICE=lx5000 -r600x600 -sOutputFile=/dev/fd/3 /dev/fd/0 3>&1 1>&2"}' > x

Comment 15 Till Kamppeter 2007-01-08 18:52:39 UTC
Thank you very much, I will change foomatic-rip appropriately.

Comment 16 Colin Brace 2007-01-19 21:06:51 UTC
(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.

Comment 17 Tim Waugh 2007-01-22 15:41:59 UTC
Colin: would you mind filing a separate bug about the pbm2l7k driver?  Choose
'ghostscript' as the component.  Thanks.

Comment 18 Till Kamppeter 2007-02-19 22:33:44 UTC
Can you replace your /usr/bin/foomatic-rip file by this one:


and then try again to print? Does this solve the problem?

Comment 19 Till Kamppeter 2007-02-20 14:36:55 UTC
Applied the fix upstream:


But please test my file posted earlier to see whether this really solves the

Comment 20 Colin Brace 2007-10-24 14:47:52 UTC
I am currently running foomatic-3.0.2-47.2.fc7 and this bug no longer occurs.

Comment 21 Tim Waugh 2007-10-25 12:43:15 UTC
Great, glad the update fixed it.  Thanks for re-testing!

Note You need to log in before you can comment on or make changes to this bug.