Description of problem: cupsd reports a sefault and aborts Version-Release number of selected component (if applicable): cupsd from cup package: Version 1.4, release 0.b2.18.fc11 How reproducible: Every time Steps to Reproduce: 1. start cupsd 2. 3. Actual results: Segmentation fault Expected results: daemon running Additional info: I don't actually use CUPS, but it was started automatically. Thus the cups.conf file I'm "using" is the default file. I just noticed the problem whilst reviewing my logwatch output. I marked this "high," but others (if this is a common problem) may find it "urgent." Here's a traceback from running cupsd -f in gdb: (gdb) bt #0 0x00007ffff4e8a9d7 in _IO_vfprintf_internal (s=0x7fffffffa560, format=<value optimized out>, ap=0x7fffffffa6d0) at vfprintf.c:1580 #1 0x00007ffff4f36c20 in ___vsnprintf_chk (s=0x7fffffffb9c0 "CONTENT_TYPE=\177", maxlen=<value optimized out>, flags=1, slen=<value optimized out>, format=0x7ffff7ff64bc "CONTENT_TYPE=%s/%s", args=0x7fffffffa6d0) at vsnprintf_chk.c:65 #2 0x00007ffff4f36b5a in ___snprintf_chk (s=0xc <Address 0xc out of bounds>, maxlen=140737488331800, flags=48, slen=18446744073709551615, format=0x0) at snprintf_chk.c:36 #3 0x00007ffff7fd7418 in snprintf (__fmt=<value optimized out>, __n=<value optimized out>, __s=<value optimized out>) at /usr/include/bits/stdio2.h:65 #4 cupsdContinueJob (__fmt=<value optimized out>, __n=<value optimized out>, __s=<value optimized out>) at job.c:873 #5 0x00007ffff7fd950b in start_job (printer=<value optimized out>, job=<value optimized out>) at job.c:3933 #6 cupsdCheckJobs (printer=<value optimized out>, job=<value optimized out>) at job.c:405 #7 0x00007ffff7fd9768 in finalize_job (job=0x7ffff8212070) at job.c:2902 #8 0x00007ffff7fdba16 in update_job (job=0x7ffff8212070) at job.c:4328 #9 0x00007ffff7fe7582 in cupsdDoSelect (timeout=<value optimized out>) at select.c:500 #10 0x00007ffff7fc0e8c in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:836
It's being triggered by one of the print jobs in the queue. Would you be able to provide a complete copy of the contents of your print queue? (You can mark it 'private'...) Become the root user (with 'su -'), then: tar jcf /tmp/spool.tar.bz2 /var/spool/cups Then, attach the /tmp/spool.tar.bz2 file using the 'Add an attachment' link on this page. If you are unwilling/unable to do this, it might be possible to narrow down which job is the problem by, instead of 'bt' at the prompt, doing this and letting me know what it says: select-frame 4 info locals print job->id print job->current_file print job->filetypes[job->current_file] Thanks for reporting the problem and helping to get it fixed!
Created attachment 350560 [details] /var/spool/cups image when segfault occures. Not much in there. After I posted the bug report, I noticed that running cupsd had created a "Print Jobs" icon in the notification error, and clicking on the icon brought up a print queue report for a job directed to /dev/null. (I have no idea how /dev/null could be a print job destination, unless I tried to print something before I defined a printer, but that doesn't seem possible.) Anyhow, that may be a clue to why the print function is having a problem.
Yes, that's basically the problem. In detail, 'job-printer-uri' is set to 'file:/dev/null' for job 4, which causes problems when cupsd tries to load that job as it isn't a valid value for job-printer-uri. In fact, I can't really see how that could have happened. I have a fix for cupsd so that it doesn't crash in this case, but the root cause of the problem is the file:/dev/null thing. The print job in this case was a photograph. Do you know which application printed it? It seems it was intended for a printer named 'ML-1430B' -- is that a print queue that exists currently?
Well, yes and no: ML-1430B is a laser printer (Samsung) on my local net that used to be available via Samba. When I moved the printer to a wirelessly-connected desktop, I discovered that Samba could not "see" the printer. I suspect that I was attempting to "tweak" the printer queue definition to establish connectivity and did something strange. This was several months ago, and my recollection is quite hazy at this point. By quickly running "system-config-printer" after a "cupsd -f" I managed to see which printers were defined. They were HP, HP Fax (both local) and ML-1430 (as a network printer). ML-1430B was not listed. The "local" devices seen to work even without cupsd running. Since the spooled item is a picture, it was most probably queued by Firefox via nautilus. (Since Firefox uses nautilus by default.) I suspect that the default queue was incorrectly set, and I failed to notice that when I pressed O.K. when asked to confirm the print. (That item was, most probably, queued while I was running on a Fedora 10 release since I only upgraded this laptop last month.) Anyhow, is there any way to "fix" the spool file so I could get cupsd running again? I have been able print to the HP printer connected to this laptop via a USB cable even with cupsd "bonked," but having it running on those rare occasions when I want to use cups might be more elegant. Hum: I have another Fedora 11 installation on a USB drive. Since there's nothing in those queues, I think I'll try the CUPS data files on this laptop from the files on the USB drive. (Hey, this is not a production system: I retired in the '90s . . .)
Oh, I'd misread the job control file; it was ML-1430, not ML-1430B. (In reply to comment #4) > Anyhow, is there any way to "fix" the spool file so I could get cupsd running > again? I have been able print to the HP printer connected to this laptop via a > USB cable even with cupsd "bonked," but having it running on those rare > occasions when I want to use cups might be more elegant. This should be sufficient: service cups stop rm -f /var/spool/cups/[cd]* /var/cache/cups/job.cache service cups start Thanks for your help!
cups-1.4-0.rc1.10.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-6680
cups-1.4-0.rc1.10.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.