[gutsy] getting "Error Printing: Too many failed attempts" error when printing through GtkPrintOperation

Bug #145278 reported by Herbert V. Riedel
44
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GTK+
Fix Released
Medium
gtk+2.0 (Ubuntu)
Fix Released
Medium
Ubuntu Desktop Bugs
Nominated for Gutsy by Herbert V. Riedel
Nominated for Intrepid by Alex
Nominated for Jaunty by Alex

Bug Description

Binary package hint: cupsys

At some point of last weeks gutsy updates, printing got broken;

printing at the commandline via lp or with xpp works; when trying to print from gnome/gtk apps which use GtkPrint I get the the error dialog window "Error Printing: Too many failed attempts";

/var/log/cups/access_log just gives
 localhost - - [26/Sep/2007:18:18:44 +0200] "GET /ppd/fs1010direct.ppd HTTP/1.1" 200 10982 - -
 localhost - - [26/Sep/2007:18:18:48 +0200] "POST /printers/fs1010direct HTTP/1.1" 400 0 unknown-0000 -
 localhost - - [26/Sep/2007:18:19:03 +0200] "POST /printers/FS-1010 HTTP/1.1" 400 0 unknown-0000 -

/var/log/cups/error_log says:
E [26/Sep/2007:18:18:48 +0200] cupsdReadClient: 7 IPP Read Error!
E [26/Sep/2007:18:19:03 +0200] cupsdReadClient: 7 IPP Read Error!

I tried strace(2)ing gtk-demo's Printing example, and saw amongst others, that cupsys returned a "Bad Request"-line...:

socket(PF_FILE, SOCK_STREAM, 0) = 7
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = -1 EOPNOTSUPP (Operation not supported)
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
connect(7, {sa_family=AF_FILE, path="/var/run/cups/cups.sock"}, 26) = 0

...

send(7, "POST /printers/FS-1010 HTTP/1.1\r\nContent-Length: 0\r\nContent-Type: application/ipp\r\nHost: localhost\r\nUser-Agent: CUPS/1.3.2\r\n\r\n", 126, 0) = 126

...

send(7, "\1\1\0\2\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5en-gbB\0\24requesting-user-name\0\3hvrE\0\vprinter-uri\0\'ipp://cervus.intra:631/printers/FS-1010B\0\10job-name\0\17gtk-demo job #1\2B\0\10PageSize\0\2A4!\0\fjob-priority\0\4\0\0\0002B\0\nResolution\0\006800dpiB\0\njob-sheets\0\4noneB\0\0\0\4noneB\0\fJCLEconomode\0\3OffB\0\tMediaType\0\6PrnDefB\0\tSmoothing\0\6MediumB\0\tInputSlot\0\10Internal!\0\tnumber-up\0\4\0\0\0\1\3", 372, 0) = 372
poll([{fd=7, events=POLLIN, revents=POLLIN|POLLERR|POLLHUP}], 1, 0) = 1
poll([{fd=7, events=POLLIN, revents=POLLIN|POLLERR|POLLHUP}], 1, 10000) = 1
recv(7, "HTTP/1.1 400 Bad Request\r\nDate: Wed, 26 Sep 2007 16:00:55 GMT\r\nServer: CUPS/1.2\r\nContent-Language: en_US\r\nUpgrade: TLS/1.0,HTTP/1.1\r\nConnection: close\r\nContent-Type: text/html; charset=utf-8\r\nContent-Length: 344\r\n\r\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\">\n<HTML>\n<HEAD>\n\t<META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset=utf-8\">\n\t<TITLE>400 Bad Request</TITLE>\n\t<LINK REL=\"STYLESHEET\" TYPE=\"text/css\" HREF=\"/cups.css\">\n</HEAD>\n<BODY>\n<H1>400 Bad Request</H1>\n<P></P>\n</BODY>\n</HTML>\n", 2048, 0) = 559

Revision history for this message
Herbert V. Riedel (hvr) wrote :

some additional logs, after setting LogLevel debug2:

d [01/Oct/2007:21:46:12 +0200] cupsdDoSelect: epoll() returned 1...
d [01/Oct/2007:21:46:12 +0200] cupsdDoSelect: Read on fd 9...
d [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9, used=0, file=-1 state=0
D [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9 POST /printers/FS-1010 HTTP/1.1
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: uri = "/printers/FS-1010"...
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location CUPS_INTERNAL_BROWSE_ACL Limit 0
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location /admin/conf Limit 7f
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location /admin Limit 7f
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: Location / Limit 7f
d [01/Oct/2007:21:46:12 +0200] cupsdFindBest: best = /
d [01/Oct/2007:21:46:12 +0200] cupsdAuthorize: con->uri="/printers/FS-1010", con->best=0x10084388(/)
d [01/Oct/2007:21:46:12 +0200] cupsdAuthorize: Authorization=""
D [01/Oct/2007:21:46:12 +0200] cupsdAuthorize: No authentication data provided.
d [01/Oct/2007:21:46:12 +0200] cupsdIsAuthorized: con->uri="/printers/FS-1010", con->best=0x10084388(/)
d [01/Oct/2007:21:46:12 +0200] cupsdIsAuthorized: level=AUTH_ANON, type=AUTH_NONE, satisfy=AUTH_SATISFY_ALL, num_names=0
d [01/Oct/2007:21:46:12 +0200] cupsdIsAuthorized: auth=AUTH_ALLOW...
d [01/Oct/2007:21:46:12 +0200] POST /printers/FS-1010
d [01/Oct/2007:21:46:12 +0200] CONTENT_TYPE = application/ipp
d [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9 con->data_encoding=HTTP_ENCODE_LENGTH, con->data_remaining=0, con->file=-1
E [01/Oct/2007:21:46:12 +0200] cupsdReadClient: 9 IPP Read Error!
D [01/Oct/2007:21:46:12 +0200] cupsdSendError: 9 code=400 (Bad Request)
D [01/Oct/2007:21:46:12 +0200] cupsdCloseClient: 9
d [01/Oct/2007:21:46:12 +0200] cupsdRemoveSelect: fd=9
d [01/Oct/2007:21:46:12 +0200] cupsdCheckJobs: 0 active jobs, sleeping=0, reload=0
d [01/Oct/2007:21:46:12 +0200] cupsdDoSelect: polling 4 fds for 1 seconds...

Revision history for this message
Herbert V. Riedel (hvr) wrote :

while looking closer at the logging output I just noticed that for some reason the request sent by the gtk apps has a "Content-Length: 0" header, which doesn't seem to be sensible...

Revision history for this message
MIke Pestorich (mmpestorich) wrote :

I am currently running the PPC port of Gutsy and am experiencing the same problem - "Error Printing: Too many failed attempts." My error and other logs show almost exactly what those in the previous post show.

I started experiencing this problem after upgrading from Feisty to Gutsy. Noticed it first when trying to print from Evince, and then later realized I could print from other programs e.g. Firefox, OpenOffice, etc presumably because they are using a different backend for passing print jobs to cups. I have tried reinstalling everything from cups to evince with no success. I have reinstalled printers. I have verified nothing is out of the ordinary in any the cups configuration files.

I have Gutsy installed on two other x86 machines and am *not* having these problems as printing seems to work as expected on these other systems.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

To the maintainer of Evince: Please assign this bug report to the library which provides printing functionality to Evince.

Changed in cupsys:
importance: Undecided → Medium
Revision history for this message
Matteo Settenvini (tchernobog) wrote :

I'm seeing this together with bug 66379: "Error in POST Success", and only on PPC.

Revision history for this message
hendrikwout (hendrikwout) wrote :

I'm haveing the same problem: "too many failed attempts".

Revision history for this message
Herbert V. Riedel (hvr) wrote :

well, this is a bug that seems to affect every application that uses the libgtk provided printing API... so it's not a evince bug...

Revision history for this message
Colin Leroy-Mira (colin-colino) wrote :

I have the same, trying to implement printing of PopplerPages (from libpoppler) using GtkPrintOperation on Gutsy.
Seems random.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug. Do you get the same issue from eog for example? Does printing to a pdf works correctly?

Changed in evince:
assignee: nobody → desktop-bugs
status: New → Incomplete
Revision history for this message
Herbert V. Riedel (hvr) wrote :

to sum it up:

printing to file (either pdf or ps) works, since it doesn't get sent via IPP

I haven't found yet(? -- see below for gedit)an application, which uses the gtk printing API and does not fail to print via cups;
applications which I have tried so far:

gtk-demo
evince
evolution
eog
gnumeric
epiphany

except for gedit, which seems to be able to print; but I'm not sure which printing API it uses, since the printing dialogs looks/feels different from the applications listed above; maybe it uses the gnome printing API?

Revision history for this message
Colin Leroy-Mira (colin-colino) wrote :

I think this bug should be on gtk+ (GtkPrintOperation) rather than evince, or maybe libpoppler...

Revision history for this message
hendrikwout (hendrikwout) wrote :

I can confirm this: eog also doesn't print. Gedit does.

Revision history for this message
Sebastien Bacher (seb128) wrote :

reassigning to gtk+2.0

Revision history for this message
Sebastien Bacher (seb128) wrote :
Changed in gtk+2.0:
status: Incomplete → Triaged
Changed in gtk:
status: Unknown → New
Revision history for this message
Herbert V. Riedel (hvr) wrote :

well, the bug became too annoying to me, and I finally got around to hunt it down to a simple integer-64/32bit-truncation bug...

sprintf was using "%lu" (on powerpc sizeof(long)==4) on a 64bit integer, which on little endian has the simple semantic of taking the lower 32bit word, but on big-endian powerpc it takes the upper 32bits of the 64bit datum, which is going to result in a 0 length for the usual print requests...

...can we get this fix in gutsy plz? :)

Revision history for this message
Colin Leroy-Mira (colin-colino) wrote :

Herbert: for me it happens on x86...

Revision history for this message
Herbert V. Riedel (hvr) wrote :

colin: then maybe you're experiencing a different bug leading to the error message? have you tried enabling debugging log output in cups?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Herbert, thanks for your work on that. Are all the people getting this issue using powerpc?

Revision history for this message
hendrikwout (hendrikwout) wrote :

I have powerpc and this bug is happens to me also.

Revision history for this message
David Erosa (erosa) wrote :

Just tried to print today and found the same bug, also on powerpc (iBook G4).

Revision history for this message
Philippe Leroux (phler2) wrote :

same here, after upgrade do gusty on ibookg4

a hint for people trying to print pdf via evince
use cups directly, until bug is solved
in a commandline
lp filename.pdf
 works fine

Revision history for this message
John Billings (jnbillings) wrote :

Same error on powerpc (Powerbook G4) when I try to print from evince. However, I can print by using lpr directly.

Revision history for this message
Dragan Stojkovic (zmajch) wrote :

Same error on my PowerMac (PPC G4 Dual).
Weird...: when i try to print a PDF from the commandline, the printer prints ... but unfortunately the font shows just lines "||II|||| |II||III" and no letters.
But I guess this is an other problem ;-)

Revision history for this message
joenix (woutersj) wrote :

I had the same problem on PowerPC and can confirm that Herbert V. Riedel's patch fixes it.

Thanks Herbert!

Revision history for this message
joenix (woutersj) wrote :

Since the gtk recompile can take quite a while, I put the libgtk package with Herbert's patch online:
http://joenix.studentenweb.org/libgtk2.0-0_2.12.0-1ubuntu3_powerpc.deb

Use at your own risk! :)

Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug should be fixed in the hardy version now

Changed in gtk+2.0:
status: Triaged → Fix Released
Changed in gtk:
status: New → Fix Released
Revision history for this message
Hollis Blanchard (hollis-penguinppc) wrote :

Could this fix be released for Gutsy please?

Revision history for this message
Flabdablet (flabdablet) wrote :

My filthy workaround for this issue:

cd /tmp
wget http://archive.ubuntu.com/ubuntu/pool/main/g/gtk+2.0/libgtk2.0-0_2.10.11-0ubuntu3_powerpc.deb
dpkg -x libgtk2.0-0_2.10.11-0ubuntu3_powerpc.deb foo
cd /usr/lib/gtk-2.0/2.10.0/printbackends
sudo mv libprintbackend-cups.so libprintbackend-cups.so.broken
sudo cp /tmp/foo/usr/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.so .

This replaces the faulty library with the version from Feisty, which apparently doesn't suffer from this bug, while leaving the package manager none the wiser. Hopefully the next upgrade will fix this rather than breaking it again.

Revision history for this message
Sebastien Bacher (seb128) wrote :

did you try on hardy if that's working correctly?

Revision history for this message
another_sam (anothersam) wrote :

also happens for me in intrepid. with evince 2.24.

ubuntu 8.10 x86
dell inspiron 9400
hp deskjet f4180

For this case, I printed a PDF once successfully (technically speaking) but I realized print margins were wrong. Then I changed them from Printer Properties > Job Options. Then I tried to print the PDF again and the message appeared: "Too many failed attempts".

Revision history for this message
Erich Pawlik (erichpawlik) wrote :

The fix doesn't work in an up to date Intrepid installation.

Ubuntu 8.10 x86, current as of November 26
Dell Vostro 1510
remote printers on a Samba server (Laserjet 4L, Magicolor 2400W)

Didn't print with Evolution 2.24.1 (message: Too many failed attempts) and Evince 2.24.1 (message: cannot prompt for authorization).

Printing to PDF is possible, also printing from Open Office.

Regards

Erich Pawlik

Revision history for this message
850001 (jacekfoo) wrote :

The same with me - I cant print from any gnome app (gedit, evolution, evince) but can print from KDE apps (Okular).

Printers are on samba servers.

Messages I get are either "Too many failed attempts" or " cannot prompt for authorization".

Revision history for this message
Alex (zk118243) wrote :

I can confirm this as well in a up to date Intrepid install. Printing works from Open Office but not gedit.

Revision history for this message
Pascal De Vuyst (pascal-devuyst) wrote :

samuel, Erich Pawlik, 850001, AlexBuck,
The bug described above only affected ppc architecture and has been fixed and is closed.
If you are on x86 you are experiencing a different problem!
Please open a new bug report and provide the information described here: https://wiki.ubuntu.com/DebuggingPrintingProblems, including your cups error_log and the output of the printingbug info script.

Revision history for this message
Arie Skliarouk (skliarie) wrote :

samuel, Erich Pawlik, 850001, AlexBuck,
I have submitted a bug report on the new issue here:
https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/359975

Feel free to contribute to it.

Changed in gtk:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.