100% CPU when disk is full

How is your disk partitioned? Is /var in a separate partition? Is it the partition with /var which got full? CUPS should only write into /var/*/cups directories while it is running.

Perhaps CUPS is waiting for space and answering as soon as some space gets free. Can you try that?

As CUPS is logging everything into the files in /var/log/cups/, a full disk can probably block all kinds of operations.

Reported upstream:

http://www.cups.org/str.php?L2032

Please answer the questions which Mike Sweet has posted in the upstream report.

/var is not a separate partition, so I can't answer your questions more specifically. Your analysis sounds correct though. I am trying the upstream-suggested gdb, and will report back here and upstream.

OK -- Here goes:

Freeing up space after cups starts using excessive CPU allows it to work properly (It receives a SIGPIPE though when run under gdb). Here's the backtrace at the point where it was using CPU:

backtrace:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7e994c3 in __write_nocancel () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7eb117e in cupsFileGetChar () from /usr/lib/libcups.so.2
#3 0xb7eb1735 in cupsFileFlush () from /usr/lib/libcups.so.2
#4 0x0807e658 in ?? ()
#5 0x080eb5b0 in ?? ()
#6 0x0809634c in _IO_stdin_used ()
#7 0x080e0bc0 in ?? ()
#8 0x0809693a in _IO_stdin_used ()
#9 0x08099400 in Sleeping ()
#10 0x0808c832 in _IO_stdin_used ()
#11 0x080e3bba in ?? ()
#12 0x00000001 in ?? ()
#13 0x00000001 in ?? ()
#14 0x000000c8 in ?? ()
#15 0x00000000 in ?? ()

Mike Sweet has posted again, can you please supply him with the needed info. Thanks.

Where can I find or how can I create a copy of Ubuntu's cupsys package with debugging enabled?

This seems to be fixed in Feisty. There it gives an error "413: Request Entity Too Large". I hope the fix can be backported to Dapper.

Marking as fixed in Feisty, thank you for checking!