Created attachment 356870 [details] test.txt as application/octet-stream Description of problem: I created in vi editor test.txt file and try to print it with lpr >>>lpr test.txt lpr: successful-ok but nothing is printed. error_log contains: D [10/Aug/2009:11:12:11 +0200] [Job 35] Auto-typing file... D [10/Aug/2009:11:12:11 +0200] [Job 35] Request file type is text/plain. D [10/Aug/2009:11:12:11 +0200] Send-Document client-error-document-format-not-supported: Unsupported format 'text/plain'! E [10/Aug/2009:11:12:11 +0200] Returning IPP client-error-document-format-not-supported for Send-Document (ipp://localhost:631/printers/Canon-iR-3170C-EUR) from localhost And the job status says it was canceled by user. Version-Release number of selected component (if applicable): cups-1.4-0.rc1.14.fc11.x86_64 How reproducible: Always Steps to Reproduce: 1. create text file in vi 2. lpr test.txt Actual results: Nothing is printed Expected results: Printing Additional info:
Created attachment 356871 [details] troubleshoot_lpr.txt
Weirdly, instead of 'text/plain' in document-format-supported there is an empty string. What does 'rpm -V cups' say?
# rpm -V cups .M....... c /etc/cups/subscriptions.conf
Please attach this file: /var/cache/cups/Canon-iR-3170C-EUR.ipp
Created attachment 356885 [details] Canon-iR-3170C-EUR.ipp
Please don't restart cups unless absolutely necessary, because the bug might disappear... Install the cups-debuginfo package: yum --enablerepo=updates-testing-debuginfo install cups-debuginfo Check it's the matching version: cups-debuginfo-1.4-0.rc1.14.fc11 Now run 'ps axf | grep [c]upsd' to find out the PID of cupsd. Let's say it's 4145. Attach to it with gdb: gdb /usr/sbin/cupsd 4145 ... (gdb) Now print out the MimeTypes array: (gdb) p NumMimeTypes 37 (gdb) p MimeTypes[0]@37 What output do you get?
(gdb) p NumMimeTypes $1 = 35 Current language: auto; currently minimal (gdb) p MimeTypes[0]@35 $3 = {0x7fe25622fc44 "application/octet-stream", 0x7fe25621aed4 "application/pdf", 0x7fe25622e044 "application/postscript", 0x7fe25621aef4 "application/rss+xml", 0x7fe25621af24 "application/vnd.cups-banner", 0x7fe25621af54 "application/vnd.cups-command", 0x7fe25621af84 "application/vnd.cups-pdf", 0x7fe25621afb4 "application/vnd.cups-postscript", 0x7fe25621afe4 "application/vnd.cups-ppd", 0x7fe25621b014 "application/vnd.cups-raster", 0x7fe25621b044 "application/vnd.cups-raw", 0x7fe25621b074 "application/vnd.hp-hpgl", 0x7fe25621b0a4 "application/x-cshell", 0x7fe25621b0d4 "application/x-csource", 0x7fe25621b104 "application/x-perl", 0x7fe25621b134 "application/x-shell", 0x7fe25621b164 "image/gif", 0x7fe25622e814 "image/jpeg", 0x7fe25622e834 "image/png", 0x7fe25622e324 "image/tiff", 0x7fe25622e344 "image/x-alias", 0x7fe25622e364 "image/x-bitmap", 0x7fe25622e974 "image/x-icon", 0x7fe25622e994 "image/x-photocd", 0x7fe25622e9b4 "image/x-portable-anymap", 0x7fe25622e194 "image/x-portable-bitmap", 0x7fe25622e1c4 "image/x-portable-graymap", 0x7fe25622fab4 "image/x-portable-pixmap", 0x7fe25622fae4 "image/x-sgi-rgb", 0x7fe25622df74 "image/x-sun-raster", 0x7fe25622fb04 "image/x-xbitmap", 0x7fe25622dfa4 "image/x-xpixmap", 0x7fe25622dfc4 "text/css", 0x7fe25622dfe4 "text/html", 0x7fe25622e004 "text/plain"}
OK, use 'detach' and 'quit' to let it carry on independently of the debugger. Let's try asking it again which document-formats it supports: python <<"EOF" import cups c=cups.Connection() print c.getPrinterAttributes('Canon-iR-3170C-EUR')['document-format-supported'] EOF
[u'application/octet-stream', u'application/pdf', u'application/postscript', u'application/vnd.cups-banner', u'application/vnd.cups-command', u'application/vnd.cups-postscript', u'application/vnd.cups-raw', u'application/vnd.hp-hpgl', u'application/x-cshell', u'application/x-csource', u'application/x-perl', u'application/x-shell', u'image/gif', u'image/jpeg', u'image/png', u'image/tiff', u'image/x-bitmap', u'image/x-photocd', u'image/x-portable-anymap', u'image/x-portable-bitmap', u'image/x-portable-graymap', u'image/x-portable-pixmap', u'image/x-sgi-rgb', u'image/x-sun-raster', u'image/x-xbitmap', u'image/x-xpixmap', u'text/html', u'']
This queue is configured to use AppSocket (as you can see from device URI socket://10.34.255.21:9100). I can also use this printer via another cups server (by using BrowsePoll in cupsd.conf). And in that case everything is OK (the file is correctly printed). [u'application/octet-stream', u'application/pdf', u'application/postscript', u'application/rss+xml', u'application/vnd.cups-banner', u'application/vnd.cups-command', u'application/vnd.cups-pdf', u'application/vnd.cups-postscript', u'application/vnd.cups-ppd', u'application/vnd.cups-raster', u'application/vnd.cups-raw', u'application/vnd.hp-hpgl', u'application/x-cshell', u'application/x-csource', u'application/x-perl', u'application/x-shell', u'image/gif', u'image/jpeg', u'image/png', u'image/tiff', u'image/x-alias', u'image/x-bitmap', u'image/x-icon', u'image/x-photocd', u'image/x-portable-anymap', u'image/x-portable-bitmap', u'image/x-portable-graymap', u'image/x-portable-pixmap', u'image/x-sgi-rgb', u'image/x-sun-raster', u'image/x-xbitmap', u'image/x-xpixmap', u'text/css', u'text/html', u'text/plain']
Yes, I think it must be some sort of memory corruption. :-( Let's try to take a look at this "" type and see what's happened to it. Start the debugger again and get it to attach to cupsd as before. First find the printer: p ((cupsd_printer_t*)Printers->elements[0])->name p ((cupsd_printer_t*)Printers->elements[1])->name p ((cupsd_printer_t*)Printers->elements[2])->name ... until we find "Canon-iR-3170C-EUR". Then look at the filetypes: p ((cupsd_printer_t*)Printers->elements[3])->filetypes->num_elements $14 = 28 p *(mime_type_t*)((cupsd_printer_t*)Printers->elements[3])->filetypes->elements[27] Here's what mine looks like: $29 = {rules = 0x7f027e33a6a0, priority = 100, super = "text", '\0' <repeats 11 times>, type = "plain\0\0\0\0\0\0\0\201", '\0' <repeats 31 times>, " \247\63~\2\177\0\0\2", '\0' <repeats 87 times>"\201, ", '\0' <repeats 15 times>"\240, \247\63~\2\177\0\0\240\246\63~\2\177\0\0\0\0\0\0\0\0\0\0\3", '\0' <repeats 15 times>, "*.txt", '\0' <repeats 54 times>} After that, take a brief look at the rules to see if they are intact: p *(*(mime_type_t*)((cupsd_printer_t*)Printers->elements[3])->filetypes->elements[27]).rules p *(*(mime_type_t*)((cupsd_printer_t*)Printers->elements[3])->filetypes->elements[27]).rules.child p *(*(mime_type_t*)((cupsd_printer_t*)Printers->elements[3])->filetypes->elements[27]).rules.child.next
Created attachment 356907 [details] gdb output
Created attachment 356914 [details] ddd output
It's hard to read but actually that output is for the 'text/html' MIME type (even though 'plain' appears later in that string, after the nul terminator). :-( OK, let's leave it for today and see if it happens again.
False alarm ! There's missing (100% my fault) texttopaps in my /usr/lib/cups/filter directory. `yum reinstall paps` fixed this problem. Closing as not a bug.
Aha, that explains it. I had been thinking it couldn't be that because the texttops filter (CUPS' own filter) would still be present... but of course our mime.confs file doesn't say to use that for text/plain. CUPS still shouldn't advertise '' an an available document format in that situation though.
Created attachment 357832 [details] Proposed patch This issue is visible when line application/octet-stream application/vnd.cups-raw 0 in /usr/share/cups/mime/mime.convs is uncommented, i.e. printing of arbitrary files without the -oraw option is enabled. Proposed patch is attached. The number of values in p->attrs is set to `cupsArrayCount(p->filetypes) + 1`. But it should be set to `cupsArrayCount(p->filetypes) + i`, where i is 0 or 1 according to whether mime type application/octet-stream is (i==0) or is not (i==1) in p->filetypes.
cups-1.4.1-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/cups-1.4.1-1.fc11
cups-1.4.1-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cups'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10152
cups-1.4.1-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cups'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10152
cups-1.4.1-4.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cups'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10152
cups-1.4.1-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.