gnome-cups-icon uses 100% CPU

[Martin Emrich]

Impact:
Occasionally, I notice that a process "gnome-cups-icon" eats 100% CPU.
Upon a "sudo killall -TERM gnome-cups-icon", it restarts and does no longer eat CPU.

Problem: When calling ippRead() in client programs, it sometimes returns IPP_IDLE which was not actually meant to get passed to outside. Thus it got handled as an error condition and the program logic got caught in a busy loop. Instead

Solution:
This was fixed upstream in http://www.cups.org/str.php?L2179 in cups 1.2.11 in February. One half of the patch was backported to Edgy's 1.2.4, and we did not get further complaints since then. The second half got shipped in gutsy, and apparently is not needed to fix the most common cases, but it has not shown any regressions for 9 months, so it should be applied, too.

Unfortunately there does not seem to be a reliable test case how to trigger this behaviour. Seems we should rely on bug reporter feedback.

[Simon Law (sfllaw)]

Hi Martin,

The next time gnome-cups-icon eats up 100% CPU, could you run
the following command which should log what the process is trying
to do?

$ strace -Ff -p $(pidof gnome-cups-icon) 2>&1 | tee /tmp/strace.log

After about ten seconds of stuff scrolling up your screen, you can
hit Control-C to stop strace.

Then, please attach /tmp/strace.log to this bug report:
https://launchpad.net/distros/ubuntu/+bug/44196/+addattachment

Thanks.

[OZ (ozorba-gmail)]

Is there a relationship between this bug and bug #43147 in any way?

Thanks,
OZ

[Martin Emrich (emme)]

Hi!

Am Sonntag, 14. Mai 2006 21:24 schrieb OZ:
> Is there a relationship between this bug and bug #43147 in any way?

Yes, a perfect duplicate ;-)

As soon as I see this behaviour again, I'll post an strace snippet.

Ciao

Martin

[Mark Smith (launchpad-marksmith)]

Hi,

I've attached an strace snippet from my machine, which is exhibiting the same behaviour.

Cheers
Mark

[Mark Smith (launchpad-marksmith)]

ooops. can't tell this is my first time using Malone, can you? ;-)

As per comment ... strace of g-c-i using 100% cpu

[Martin Pitt (pitti)]

Hm, it would be interesting to see what is behind the file descriptor 16.

[Simon Law (sfllaw)]

Mark,

Could you please attach a fuller version of the strace? I'd like to see
what's open()ed on file descriptor 16.

Thanks.

[Patrik Jansson (patrikja)]

I also (sometimes) have this problem with gnome-cups-icon getting into a "spin-lock" taking ~100% CPU.

The strace output only shows _many_ copies of these two lines:

[pid 5604] recv(16, "", 2048, 0) = 0
[pid 5604] time(NULL) = 1148885860

where the time slowly increases (about 8000 copies of those two lines before the time counter increases by one!).

After hitting C-c on the strace call, gnome-cups-icon has the attached open files - note that file descriptor 16 is

gnome-cup 4734 patrikj 16u IPv4 12465 TCP localhost.localdomain:39757->localhost.localdomain:ipp (CLOSE_WAIT)

/Patrik

PS. My system is a Vaio laptop with ubuntu dapper updated yesterday (060528).

[Patrik Jansson (patrikja)]

I just wanted to add that this behaviour remains. lsof while g-c-i is looping shows essentially the same as the one attached above with file descriptor 16 still being the ipp connection.

gnome-cup 4730 patrikj 16u IPv4 12905 TCP localhost.localdomain:41964->localhost.localdomain:ipp (CLOSE_WAIT)

As in the first post, if I kill it, it restarts nicely without the 100% usage.

[Nikolaus Rath (nikratio)]

This bug is marked "Needs Info", but I wasn't able to find any unanswered requests for info. So if there's something missing, please post what kind of info is needed, because I'd like to provide it (I also suffer from this bug and it's quite annoying because it prevents CPU frequency scaling on my laptop).

[seede (seede)]

Gzipped because it was large. I had the same problem with g-c-i eating up cpu time.

[Simon Law (sfllaw)]

Ah. I see now.

The strace is attached too late. Could someone do this instead?

$ killall gnome-cups-icon
$ strace -Ff -e network gnome-cups-icon 2>&1 | tee /tmp/strace.log

Compressing the log is perfectly acceptable.

Thanks!

[OZ (ozorba-gmail)]

This is all I get... Is it what is expected?

OZ

socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 10
connect(10, {sa_family=AF_FILE, path="/tmp/.ICE-unix/5447"}, 21) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 11
connect(11, {sa_family=AF_FILE, path="/tmp/orbit-oz/linc-1480-0-379283c04147a"}, 42) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 12
setsockopt(12, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(12, {sa_family=AF_FILE, path="/tmp/orbit-oz/linc-1782-0-47f5c93cbc73b"}, 42) = 0
listen(12, 10) = 0
getsockname(12, {sa_family=AF_FILE, path="/tmp/orbit-oz/linc-1782-0-47f5c93cbc73b"}, [42]) = 0
accept(12, {sa_family=AF_FILE, path=@}, [2]) = 13
socket(PF_FILE, SOCK_STREAM, 0) = 15
connect(15, {sa_family=AF_FILE, path="/tmp/orbit-oz/linc-157f-0-5fccae0528ae"}, 41) = 0
accept(12, {sa_family=AF_FILE, path="YC@"}, [2]) = 14

[Nikolaus Rath (nikratio)]

I suppose not. You have to wait until it actually consumes CPU.

[OZ (ozorba-gmail)]

This is the file that gives the result of

$ strace -Ff -e network gnome-cups-icon 2>&1 | tee -a /tmp/strace.log

after running it several times following

$ killall gnome-cups-icon

I foolowed the CPU usage and as it reached the 100% I ran the command.

Hope it helps.

OZ

[Magnus (koma-lysator)]

Here is a trace I did when my (newly updated) cups icon consumed 100% CPU.

[Prizrak (slavachem)]

I discovered some more info on this. It seems that the manager only hangs when the auto detect fails. I tried two printers on the desktop and one was an HP that got picked up right away and another was a Lexmark that was not detected, it only hung when it couldn't detect the printer.

[Prizrak (slavachem)]

Since I can't edit (and was sure the following info was already in there) here is a related problem. I only experience the behavior described when adding a printer on both my desktop and laptop machines with Dapper 6.06 installed. System monitor doesn't show g-c-i taking up all of the CPU however the CPU is fully utilized and the only cups related service shown is g-c-i. Behavior is only exhibited while attempting to add a printer.

[Topper (t-harley)]

I confirm this bug on Dapper LTS. Eats 100% CPU on one core of my Athlon x2. I'll try to strace next time it happens.

[Richard Wilbur (richard-wilbur)]

I'm seeing this on Dapper Monday 14 August 2006 with no outstanding updates. Was this fixed on 6.06.1? My system is iBook 14" PPC G4 1.43GHz 1.5GB RAM 100GB HD.

I decided to poke around just a little and ran:

gdb /usr/bin/gnome-cups-icon 4247

to attach to the running process. Then "bt" to get a backtrace and it responded with ...

(gdb) bt
#0 0x0ee651c4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1 0x0ef78f94 in gnome_cups_request_execute_async ()
   from /usr/lib/libgnomecups-1.0.so.1
<snip>
#13 0x0ef78f94 in gnome_cups_request_execute_async ()
   from /usr/lib/libgnomecups-1.0.so.1
Previous frame inner to this frame (corrupt stack?)
(gdb)

Stack levels 1-13 were identical.

I guess to understand this better I'd have to get the source code for libgnomecups. Which package would that be?

Thanks,

Richard

[Richard Wilbur (richard-wilbur)]

Just for kicks I typed:

(gdb) next
Single stepping until exit from function pthread_cond_wait@@GLIBC_2.3.2,
which has no line number information.

and the processor usage immediately rose to 100% (with CPU fan start). It doesn't seem to make it back from that call, as far as I can see. On the other hand, why should pthread_cond_wait() take up large amounts of CPU time? That seems like a poor implementation. Maybe gdb is confused about what call gnome-cups-icon is actually in because of the above noted stack problems.

Any thoughts?

Richard

[Jan Groenewald (jan-aims)]

I can confirm this bug on Dell Optiplex Desktops running an up-to-date dapper. This problem did not exist on breezy.

Note that I did not use GUI tools to configure CUPS, I edited
/etc/cups/cupsd.conf and added ServerName myprintserver.mynetwork.ac.za. Printing is working, and sometimes after a print job the gnome-cups-icon uses 90% or more CPU until I killall gnome-cups-icon.

It did not immediately reproduce when I sent a printjob to test, but If I see it again I'll also take an strace and send it in.

[Ante Karamatić (ivoks)]

On Pet, 2006-08-25 at 07:03 +0000, Jan Groenewald wrote:

> Note that I did not use GUI tools to configure CUPS, I edited
> /etc/cups/cupsd.conf and added ServerName
> myprintserver.mynetwork.ac.za. Printing is working, and sometimes
> after a print job the gnome-cups-icon uses 90% or more CPU until I
> killall gnome-cups-icon.

Could you add your cupsd.conf? And, do you have
myprintserver.mynetwork.ac.za in /etc/hosts?

--
Ante Karamatić <email address hidden>
PGP: 0xD3BDA225

[Jan Groenewald (jan-aims)]

Apologies. That ServerName line is in /etc/cups/client.conf not /etc/cups/cupsd.conf.
I haven't touched the default cupsd.conf. I attach client.conf. I did the ServerName and restarted CUPS, and it seemed to work. The gnome-cups-icon problem is intermittent, not easily reproducable, but has happened about 4 times in as many days now.

No, myprintserver is not in /etc/hosts, but it is resolving fine. It only happens after print jobs, so you think somehow DNS is involved?

Still waiting for it to happen again now...

[Ante Karamatić (ivoks)]

On Pet, 2006-08-25 at 09:13 +0000, Jan Groenewald wrote:
> Apologies. That ServerName line is in /etc/cups/client.conf not
> /etc/cups/cupsd.conf. I haven't touched the default cupsd.conf. I
> attach client.conf. I did the ServerName and restarted CUPS, and it
> seemed to work. The gnome-cups-icon problem is intermittent, not
> easily reproducable, but has happened about 4 times in as many days
> now.

/etc/cups/client.conf has nothing to do with cupsys-server. Don't run
cupsys-server if you use cupsys-client.

> No, myprintserver is not in /etc/hosts, but it is resolving fine. It
> only happens after print jobs, so you think somehow DNS is involved?

I'm not sure. Just getting more info :)

--
Ante Karamatić <email address hidden>
PGP: 0xD3BDA225

[Jan Groenewald (jan-aims)]

OK, it is actually a networked lab where a few PC's run cupsys-server for connected printers but it has never interfered (on breezy) with the majority which use a network-wide CUPS server on another host. I'll turn it off on this box and see if the problem occurs again.

[Andreas Schildbach (schildbach)]

I can confirm this bug (Ubuntu Dapper, Dell Latitude X1, I do not even own a printer)

[Jan Groenewald (jan-aims)]

OK, it's happened again this morning. Not after a printjob.
The cups server is not running, and this machine is a client
to a CUPS server on another host.

The strace as in other comments gave (and it wouldn't
ctl-c, I had to kill -9 the strace):

Process 3843 attached with 9 threads - interrupt to quit
[pid 28995] gettimeofday( <unfinished ...>
[pid 3836] futex(0x80c4620, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 3837] futex(0x80c4620, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 3838] futex(0x80c4620, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 3839] futex(0x80c4620, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 3840] futex(0x80c4620, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 3841] futex(0x80c4620, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 3842] futex(0x80c4620, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 28995] <... gettimeofday resumed> {1156661704, 205634}, NULL) = 0
[pid 28995] ioctl(3, FIONREAD, [0]) = 0
[pid 28995] gettimeofday({1156661704, 206090}, NULL) = 0
[pid 28995] poll( <unfinished ...>
[pid 3843] time(NULL) = 1156661704
[pid 3843] recv(16, "", 583, 0) = 0
[pid 3843] time(NULL) = 1156661704

with the last two lines repeated ad infinitum. That's the recv from File Descritpor 16, right? I don't know if this helps:

$lsof -p 28995
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
gnome-cup 28995 jan cwd DIR 0,22 12288 8683893 /var/autofs/misc/home/jan (homeserver.aims.ac.za.:/home)
gnome-cup 28995 jan rtd DIR 3,2 4096 2 /
gnome-cup 28995 jan txt REG 3,2 22744 603035 /usr/bin/gnome-cups-icon
gnome-cup 28995 jan mem REG 0,0 0 [heap] (stat: No such file or directory)
gnome-cup 28995 jan DEL REG 0,8 28901402 /SYSV00000000
gnome-cup 28995 jan mem REG 3,2 72200 606506 /usr/lib/gtk-2.0/2.4.0/engines/libubuntulooks.so
gnome-cup 28995 jan mem REG 3,2 208464 652292 /usr/lib/locale/en_ZA.utf8/LC_CTYPE
gnome-cup 28995 jan mem REG 3,2 880086 652291 /usr/lib/locale/en_ZA.utf8/LC_COLLATE
gnome-cup 28995 jan mem REG 3,2 37432 475548 /lib/tls/i686/cmov/libnss_files-2.3.6.so
gnome-cup 28995 jan mem REG 3,2 33616 475552 /lib/tls/i686/cmov/libnss_nis-2.3.6.so
gnome-cup 28995 jan mem REG 3,2 32348 475544 /lib/tls/i686/cmov/libnss_compat-2.3.6.so
gnome-cup 28995 jan mem REG 3,2 80876 604729 /usr/lib/libsasl2.so.2.0.19
gnome-cup 28995 jan mem REG 3,2 44884 604574 /usr/lib/liblber.so.2.0.130
gnome-cup 28995 jan mem REG 3,2 213792 604580 /usr/lib/libldap_r.so.2.0.130
gnome-cup 28995 jan mem REG 3,2 5524 472403 /lib/libcom_err.so.2.1
gnome-cup 28995 jan mem REG 3,2 14164 603384 /usr/lib/libkrb5support.so.0.0
gnome-cup 28995 jan mem REG 3,2 142980 602792 /usr/lib/libk5crypto.so.3.0
gnome-cup 28995 jan mem REG 3,2 496092 603102 /usr/lib/libkrb5.so.3.2
gnome-cup 28995 jan mem REG 3,2 109672 602790 /usr/lib/libgssapi_krb5.so.2.2
gnome-cup 28995 jan mem REG 3,2 77176 475542...

[Simon Law (sfllaw)]

Yes. It's basically looping trying to read from a TCP connexion that
has been closed on it.

[Martin Pitt (pitti)]

Debian has a patch which fixes this in cupsys.

[Martin Pitt (pitti)]

 cupsys (1.2.4-2ubuntu1) edgy; urgency=low
 .
   * Merge recent Debian changes to get some bug fixes and new upstream version
     1.2.4 (UVF exception approved by Matt Zimmerman):
     - The --with-printcap configure option did not work (STR #1984)
     - The character set reported by cupsLangGet() did not always reflect the
       default character set of a given locale (STR #1983)
     - Older Lexmark and Tektronix printers did not work with IPP (STR #1980)
     - Failsafe printing did not work (PR #6328)
     - Some web interface redirects did not work (STR #1978)
     - The web interface change settings button could introduce a "Port 0" line
       in cupsd.conf if there was no loopback connection available (STR #1979)
     - The web interface change settings and edit configuration file buttons
       would truncate the cupsd.conf file (STR #1976)
     - The German web interface used the wrong printer icon images (STR #1973)
     - (The other changes of 1.2.4 were already present as patch in the
       previous version.)
     - Remove transitional PPD symlink which is not necessary any more and just
       causes loops. Closes: LP#62198
     - Fix CPU hogging of gnome-cups-manager. Closes: LP#44196
   * Add debian/patches/ubuntu-default-error-policy-retry-job.dpatch:
     - Do not stop the printer if a job failed, just reattempt it. The default
       policy might be suitable for large offices with an admin, but it
       puts home users at loss. Thanks to Till Kamppeter for the patch!
       Closes: LP#41313

[Nick Demou (ndemou)]

I've accidentaly clicked "Also needs fix here" button of this bug thinking that it would link to some more info instead of performing an action. I'm totaly lost with regards to malone and I can't find how to undo my action.

[Johnathon (kirrus)]

Hi,

We've put a LTSP system running Ubuntu dapper and have this problem: its grabbing 100% CPU on one of the cores of our app server.

I notice a fix has been released for edgy, can anyone tell me: when will one be released for Dapper?

[Martin Pitt (pitti)]

Right now it is not yet decided whether this will be fixed for Dapper at all, but I opened and confirmed a Dapper task, since it's pretty annoying.

Matt, what do you think, do you agree to have this fixed for Dapper, too?

[Johnathon (kirrus)]

Hi,

We really could use a fix for this one: it is grabbing 1/4 of the processing power on our customers application server, and putting load up to 25. It is effectivly limiting the number of users we can deploy onto that server to ~20, instead of 30+.

We are planning to put a load balancer / failover system in, which (for the short term at least) would solve it, but thats Phase 2 of the install, and we're still completing Phase 1.

Realisticaly, we can't move this system from Dapper to Edgy, as it is critical to their buisness, it needs to be on the more stable platform.

Thanks,
Johnathon

[Matt Zimmerman (mdz)]

On Fri, Oct 13, 2006 at 06:23:22AM -0000, Martin Pitt wrote:
> Right now it is not yet decided whether this will be fixed for Dapper at
> all, but I opened and confirmed a Dapper task, since it's pretty
> annoying.
>
> Matt, what do you think, do you agree to have this fixed for Dapper,
> too?

If there is a safe and uninvasive patch, it's worth considering.

--
 - mdz

[Johnathon (kirrus)]

Hi,

We've found that disabling gnome-cups-icon (by renaming it gnome-cups-icon-old) has fixed the problem. As the cause program is no longer running, our current load averages are 0.30, 0.21, 0.23. =)

Regards,

Johnathon

[Philipp Kohlbecher (xt28)]

It would still be nice to see a patch for dapper; after all, it comes with long-term support...

[Johnathon (kirrus)]

Could we have a backport of the fix to Dapper please? This is quite a critical problem for business LTSP systems.

[WW (wweckesser)]

Iam running dapper, and I am having the same problem. Others have reported the problem in the forums: http://ubuntuforums.org/showthread.php?t=245067

Please fix this, if possible! A rogue process using 100% CPU is a form of denial-of-service.

[Johnathon (kirrus)]

Until a dev gets round to looking at this, its going to be a waiting game, I'm afraid. You can disable the program by renaming it (gnome-cups-icon to gnome-cups-icon-old) or deleting it, and then restarting your machine.

Cupsys currently has 108 bugs listed.. it may take a while.

[Matt Zimmerman (mdz)]

On Sat, Apr 28, 2007 at 07:16:13PM -0000, Johnathon wrote:
> Until a dev gets round to looking at this, its going to be a waiting
> game, I'm afraid.

Developers have looked at this bug, and it was fixed 6 months ago in Ubuntu
6.10.

--
 - mdz

[Fabien (fabien-ubuntu)]

So, what about dapper ??

It's supposed to be supported to 2009 !

I have this bug on all workstations in my lab, it slows down every user...
It's time to do something...

Thanks.

[Jan Groenewald (jan-aims)]

Hi

On Wed, Jun 06, 2007 at 08:27:25AM -0000, Fabien wrote:
> So, what about dapper ??
> It's supposed to be supported to 2009 !
> I have this bug on all workstations in my lab, it slows down every user...
> It's time to do something...

Time for you to give better bug reports?

We use dapper for servers -- long term stable support.

We use feisty for dekstops - muich new science software and codecs for
multimedia.

Jan

--
   .~.
   /V\ Jan Groenewald
  /( )\ www.aims.ac.za
  ^^-^^

[Johnathon (kirrus)]

Jan: Can you clarify for me please? I don't quite understand where you're coming from / what you're trying to say.

I think, that someone will have to file a proper backport request for this one. I've been meaning to for a while, but haven't quite got round to it (work is manic atm, and the quick and dirty fix has solved this issue for us).

Fabien: A quick and dirty fix, delete the file. "gnome-cups-icon".

[Fabien (fabien-ubuntu)]

Thanks Johnathon, that's a useful comment.

I also found this from debian :

Disabling gnome-cups-icon
=========================

 On large networks, with shared CUPS servers, it might be desirable not to
 start the gnome-cups-icon which regularly polls the CUPS server for the
 status of jobs.

 gnome-cups-icon is launched by gnome-session by default, but this is
 configurable via gnome-session-properties.

gnome says that it's a cupsys problem. It's true, but this is not a reason to not fix the client part.
Even a malfunctionned server should lead a client to eat all cpu, isn't it ?

[Fabien (fabien-ubuntu)]

Ooops, I mean "should *NOT*" :)

[Jan Groenewald (jan-aims)]

Hi

I am terribly sorry. I am a bit busy and thought this was another
Fabien, one that I support, asking me a question.

I shall spank myself for not reading the subject and email properly.

On Wed, Jun 06, 2007 at 08:59:28AM -0000, Johnathon wrote:
> Jan: Can you clarify for me please? I don't quite understand where
> you're coming from / what you're trying to say.
> I think, that someone will have to file a proper backport request for
> this one. I've been meaning to for a while, but haven't quite got round
> to it (work is manic atm, and the quick and dirty fix has solved this
> issue for us).
> Fabien: A quick and dirty fix, delete the file. "gnome-cups-icon".

A backport request will be a good idea (though I do run feisty now,
and this problem is no longer an issue for me).

In the meantime, while you wait for the fix, disable gnome-cups-icon:
$ sudo mv /usr/bin/gnome-cups-icon{,.broken}

cheers,
Jan

--
   .~.
   /V\ Jan Groenewald
  /( )\ www.aims.ac.za
  ^^-^^

[Peter Belew (peterbe)]

I observed this on one of my 6.06 LTS systems a few days ago - running top showed that gnome-cups-icon was using 100% or nearly 100% of the CPU.

While there is a known workaround (deleting or renaming gnome-cups-icon), I feel that this should be fixed in this LTS release ASAP, since this IS an LTS release with many months of bugfixing support ahead of it. This is a bug that can cause severe degradation of system performance. I run 6.06 LTS on some systems precisely because I expect them to be stable.

Since apparently a bug fix exists for later releases, I would expect that a backport of this fix would be feasible.

Cheers,

Peter

[Steve Peters (steve-fisharerojo)]

Agreed. Its time to fix this problem.

Steve

On 11/5/07, Peter Belew <email address hidden> wrote:
> I observed this on one of my 6.06 LTS systems a few days ago - running
> top showed that gnome-cups-icon was using 100% or nearly 100% of the
> CPU.
>
> While there is a known workaround (deleting or renaming gnome-cups-
> icon), I feel that this should be fixed in this LTS release ASAP, since
> this IS an LTS release with many months of bugfixing support ahead of
> it. This is a bug that can cause severe degradation of system
> performance. I run 6.06 LTS on some systems precisely because I expect
> them to be stable.
>
> Since apparently a bug fix exists for later releases, I would expect
> that a backport of this fix would be feasible.
>
> Cheers,
>
> Peter
>
> --
> gnome-cups-icon uses 100% CPU
> https://bugs.launchpad.net/bugs/44196
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Martin Pitt (pitti)]

I extracted the patch and will upload a dapper update.

Does anyone have a monkey-proof recipe how to trigger this condition?

[Martin Pitt (pitti)]

Debdiff used for dapper.

[Martin Pitt (pitti)]

I applied the patch and tested it on my dapper installation.

Uploaded and accepted into dapper-proposed. Can all bug reporters please install this version, give it a test, and report back here? Thank you!

 cupsys (1.2.2-0ubuntu0.6.06.5) dapper-proposed; urgency=low
 .
   * Add debian/patches/60_ipp_read_busy_loop.dpatch:
     - Fix logic error that causes IPP client programs like gnome-cups-icon to
       sometimes get into a state where it uses 100% CPU time.
     - Properly handle ippReadIO() encountering IPP_IDLE and make sure to never
       return this to the outside world, since it is interpreted as an error
       condition which causes a busy loop.
     - Error out if the read callback doesn't return a value/group tag, which
       would confuse the higher layers.
     - Patch backported from upstream SVN (fixed in 1.2.11).
     - LP: #44196

[Martin Pitt (pitti)]

Can anyone please test this and give some feedback how the cupsys in dapper-proposed behaves? Without any test results, this cannot proceed to -updates.

[Kees Cook (kees)]

This has been superseded by a security update. Please remerge. Dapper debdiff from 1.2.2-0ubuntu0.6.06.4 attached...

[Martin Pitt (pitti)]

I reapplied the pending stable release update for this bug to dapper-proposed on top of Kees' security update. Please test and give feedback here.

[Matt Zimmerman (mdz)]

OK, folks. Substantial effort has been devoted to this issue by the development team, and now they are asking for you to confirm that your problem has been addressed.

WW? Johnathon? Philipp Kohlbecher? Fabien? Peter Belew? Steve Peters? You've all indicated that this is an issue for you on 6.06 LTS. Please take a moment to test the update which has been prepared and send your feedback.

[OZ (ozorba-gmail)]

It appears that this problem no longer exists in 7.10. Thanks for all your efforts!

OZ

[Timo Aaltonen (tjaalton)]

OZ: that was known all along (it was fixed in edgy).

I've installed the new version in two workstations, and will monitor them for a couple of days in case g-c-i eats cpu again.

[Fabien (fabien-ubuntu)]

Thanks for your efforts.
In my environment, the problem is that the cups server is running on another distribution, not on Ubuntu.
I must confess I still don't understand why there's no fix in gnome-cups-manager which contains gnome-cups-icon
I fully understand there's a bug in cups, but that's not a reason for a client to use 100% of CPU.
IMHO, this problem should also be fixed on the gnome part. But that's not your responsability...

Anyway, I did something radical, I just removed the gnome-cups-icon everywhere and that's it (I don't have any problem with KDE) :)

[Timo Aaltonen (tjaalton)]

Fabien: you don't need to update the server, only the packages on the client.

[Fabien (fabien-ubuntu)]

You mean the bug is in the cups library used by gnome-cups-icon ?
Oops... Completely sorry, I missed that point :(
I thought only the cups server was patched...

I will test the updates right now.

[Johnathon (kirrus)]

We are no longer using Dapper server. This and a couple of other bugs caused us to move all our servers to edgy/fiesty.

[Martin Pitt (pitti)]

Fabien, Timo, what's your experience so far?

[Timo Aaltonen (tjaalton)]

A week later and gnome-cups-icon still doesn't use any CPU on either of the two computers, so it seems to work just fine.

[Martin Pitt (pitti)]

Copied to dapper-updates.

[Fabien (fabien-ubuntu)]

I can confirm it's perfectly fine for me also.

Thanks a lot !