Comment 4 for bug 936647

I seem to suffer from the same problem, so here is what I could find out so far. Attached with strace, this is the only thing that eats up all CPU power:

[...]
select(6, [0 4], [], NULL, {5, 0}) = 2 (in [0 4], left {4, 999998})
poll([{fd=4, events=POLLIN}], 1, 1000) = 1 ([{fd=4, revents=POLLIN|POLLHUP}])
read(4, "", 16388) = 0
select(6, [0 4], [], NULL, {5, 0}) = 2 (in [0 4], left {4, 999997})
poll([{fd=4, events=POLLIN}], 1, 1000) = 1 ([{fd=4, revents=POLLIN|POLLHUP}])
read(4, "", 16388) = 0
select(6, [0 4], [], NULL, {5, 0}) = 2 (in [0 4], left {4, 999998})
poll([{fd=4, events=POLLIN}], 1, 1000) = 1 ([{fd=4, revents=POLLIN|POLLHUP}])
read(4, "", 16388) = 0
[...]

In gdb, I only managed to get this:

Thread 1 (Thread 0x7fcc62d7d740 (LWP 20393)):
#0 0x00007fcc62723d10 in __read_nocancel () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007fcc6296b7c4 in cupsSideChannelRead () from /usr/lib/x86_64-linux-gnu/libcups.so.2
#2 0x00007fcc62dac950 in main ()

Maybe it's related that with this cups version all command line tools like lpq and lpstat ceased to work, too. I can see the usual linefeeds, but all lines are empty. For example, "lpstat -t" gives 12 empty lines. I also used strace to get a clue, and it seems that the server gives empty strings via the socket.