Created attachment 401821 [details]
File: backtrace

That printer is giving a corrupted Device ID.  I have a 6MP here and it doesn't do that... seems like something is up with yours, or with the USB transport.  Does it give the same Device ID when connected via parallel port? (Use 'lpinfo -l -v' to see the Device ID.)

Anyway, CUPS ought to treat this data more carefully than it does and not assume that the ID will be valid.

(In reply to comment #2)
> That printer is giving a corrupted Device ID.  I have a 6MP here and it doesn't
> do that... seems like something is up with yours, or with the USB transport. 
> Does it give the same Device ID when connected via parallel port? (Use 'lpinfo
> -l -v' to see the Device ID.)

I don't have a parallel port currently available, but I can report that the patch http://cups.org/strfiles/3534/0001-Treat-Device-IDs-more-carefully-in-case-they-are-cor.patch fixes this. Thank you very much for the fast response.

I just tried with a different 6MP and a different USB to lp converter, both also show the seg fault. I don't have a F12 machine ready with a physical parport, but on a CentOS 5.4 machine I get this:

Device: uri = parallel:/dev/lp0
        class = direct
        info = LPT #1
        make-and-model = Unknown
        device-id = 

Btw. the same model of USB to lp converter works on my F12 machine with a LaserJet 1100 without a problem (it was added automatically). But even with the patched cups, I still get a segfault with the second 6MP and the other USB to lp converter:
#0  _wordcopy_fwd_dest_aligned (dstp=140734921371632, srcp=140734921371648, len=2305843009213692208) at wordcopy.c:196
#1  0x00007fcf3e5c99ae in memmove (dest=0x7fff66feb980, src=<value optimized out>, len=18446744073709551614) at memmove.c:73
#2  0x00007fcf3fefb775 in backendGetDeviceID (fd=<value optimized out>, device_id=0x7fff66feb980 "8\252\346m\204\214\350ͭ>\317\177", 
    device_id_size=<value optimized out>, make_model=0x7fff66feb180 "", make_model_size=1024, scheme=0x7fcf3fefd890 "", uri=<value optimized out>, 
    uri_size=1024) at ieee1284.c:218
#3  0x00007fcf3fefa48d in list_devices () at usb-unix.c:295

This is now with cups-1.4.2-29.fc12 from CVS but your patch added.

Thanks, I've attached another patch to the upstream bug to guard against this case.

The fact remains that these IDs are incorrect.  This one was:

"8\252\346m\204\214\350ͭ>\317\177"

The first one was:

"MANUFATSCRIPT;MODEL:HP LaserJet 6MP;CLASS:PRINTER;DESCRIPTION:Hewlett-Packard LaserJet 6MP Printer;RINTER;DESCRIPTION:Hewlett-Packard LaserJet 6MP Printer;"

The Device ID from a correctly functioning HP LaserJet 6MP is this:

"MANUFACTURER:Hewlett-Packard;COMMAND SET:PJL,MLC,PCLXL,PCL,POSTSCRIPT;MODEL:HP LaserJet 6MP;CLASS:PRINTER;DESCRIPTION:Hewlett-Packard LaserJet 6MP Printer;"

The crash is now gone. Later today or tomorrow I'll boot a F13alpha on my system with a parport to see what it reports.

Btw. will the automatic printer installation work with these broken device IDs? At least on windows the first setup made it automatically setup the printer.

(In reply to comment #6)
> Btw. will the automatic printer installation work with these broken device IDs?
> At least on windows the first setup made it automatically setup the printer.    

No.  They are broken beyond recognition.

So the indication is that the printer is functioning correctly, but that the communication channel is not working reliably, at least for IEEE 1284 Device ID retrieval.

I wonder if the problem is something to do with the USB hardware on the host side, or with the kernel.

The parallel port test will help to confirm that the printer is not at fault anyway.

I forgot about the other machine with parport I have here and I just booted F13alpha on it and lpinfo -l -v did not return a device ID for the 2nd LJ 6 MP. I do not have access to the first one currently. I tried both cups with release 29 and 34.

For the LaserJet 1100 the device ID via the USB-parport converter looks good btw: 

MFG:Hewlett-Packard;MDL:HP LaserJet 1100;DES:HP LaserJet 1100 Printer;CMD:MLC,PCL,PJL;CLS:PRINTER;REV:1.1;IO PREFS:ECP18;

Thanks.  The HP LJ 1100 already seems to be correct in all packages which support it (foomatic-db, gutenprint, hplip).

The CUPS patch for handling broken Device IDs has been accepted upstream now.

*** Bug 587594 has been marked as a duplicate of this bug. ***

The relevant code from the kernel driver:

#define LP_PERRORP      0x08  /* unchanged input, active low */
#define LP_POUTPA       0x20  /* unchanged input, active high */
#define LP_PSELECD      0x10  /* unchanged input, active high */

#define USBLP_REQ_GET_STATUS                    0x01
#define usblp_read_status(usblp, status)\
        usblp_ctrl_msg(usblp, USBLP_REQ_GET_STATUS, USB_TYPE_CLASS, USB_DIR_IN, USB_RECIP_INTERFACE, 0, status, 1)

static const char *usblp_messages[] = { "ok", "out of paper", "off-line", "on fire" };

... usblp_read_status(usblp, usblp->statusbuf) ...
... status = *usblp->statusbuf; ...

        if (~status & LP_PERRORP)
                newerr = 3;
        if (status & LP_POUTPA)
                newerr = 1;
        if (~status & LP_PSELECD)
                newerr = 2;
...
        if (newerr != err) {
                printk(KERN_INFO "usblp%d: %s\n",
                   usblp->minor, usblp_messages[newerr]);

Sorry, ignore comment #11, was intended for bug #488949.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping