Created attachment 772137 [details] stp-bjc-PIXMA-iP6100D.5.2.ppd.gz Description of problem: The attached file fails cupstestppd, but when decompressed it works perfectly. Running under the debugger it seems that a CRC check fails and so the decompression is stopped and the file object marked as EOF. Version-Release number of selected component (if applicable): cups-1.6.2-15.fc19.x86_64 How reproducible: 100% Steps to Reproduce: 1.cupstestppd -W sizes stp-bjc-PIXMA-iP6100D.5.2.ppd.gz; echo $? 2.gunzip -c stp-bjc-PIXMA-iP6100D.5.2.ppd.gz | cupstestppd -W sizes -; echo $? Actual results: Step 1 gives exit code 3 ("the PPD file contains format errors that cannot be skipped"). Expected results: Both steps should give exit code 0. Additional info: The file came from gutenprint-5.2.9-12.fc19, running 'fedpkg local' and then 'make check' in the source directory.
This fails in every branch I have tried (trunk, 1.6, 1.5, 1.4, 1.2).
Looks like a sign extension problem. cups/file.c 2418 unsigned char trailer[8]; /* Trailer bytes */ 2419 uLong tcrc; /* Trailer CRC */ [...] 2432 tcrc = (((((trailer[3] << 8) | trailer[2]) << 8) | trailer[1]) << 8) | 2433 trailer[0]; 2434 (gdb) 2435 if (tcrc != fp->crc) At this point, we have: (gdb) p/x fp->crc $19 = 0xda86f4ad (gdb) p/x tcrc $20 = 0xffffffffda86f4ad (gdb) whatis fp->crc type = uLong (gdb) whatis tcrc type = uLong (uLong is an unsigned long) /usr/include/zconf.h 368:typedef unsigned long uLong; /* 32 bits or more */ The instructions look like: fp->crc = ... 0x00007ffff7990712 <+802>: callq 0x7ffff797d2c0 <crc32@plt> 0x00007ffff7990717 <+807>: mov %rax,0x2098(%rbx) if (status == Z_STREAM_END) 0x00007ffff799071e <+814>: jmpq 0x7ffff79904ca <cups_fill+218> if (read(... 0x00007ffff7990723 <+819>: mov (%rbx),%edi 0x00007ffff7990725 <+821>: mov $0x8,%edx 0x00007ffff799072a <+826>: mov %r14,%rsi 0x00007ffff799072d <+829>: callq 0x7ffff797cdd0 <read@plt> ...< sizeof(trailer)) 0x00007ffff7990732 <+834>: cmp $0x7,%rax 0x00007ffff7990736 <+838>: jbe 0x7ffff799076e <cups_fill+894> tcrc = ... 0x00007ffff7990738 <+840>: movzbl 0x3(%rsp),%eax 0x00007ffff799073d <+845>: movzbl 0x2(%rsp),%edx 0x00007ffff7990742 <+850>: shl $0x8,%eax 0x00007ffff7990745 <+853>: or %edx,%eax 0x00007ffff7990747 <+855>: movzbl 0x1(%rsp),%edx 0x00007ffff799074c <+860>: shl $0x8,%eax 0x00007ffff799074f <+863>: or %edx,%eax 0x00007ffff7990751 <+865>: movzbl (%rsp),%edx 0x00007ffff7990755 <+869>: shl $0x8,%eax 0x00007ffff7990758 <+872>: or %edx,%eax 0x00007ffff799075a <+874>: cltq if (tcrc != fp->crc) => 0x00007ffff799075c <+876>: cmp %rax,0x2098(%rbx) The cltq instruction sign-extends the 4-byte value, leading to the problem at hand. The solution is to do the type promotion in two parts (this is what gzip does).
Created attachment 772198 [details] cups-gz-crc.patch
cups-1.6.3-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/cups-1.6.3-1.fc19
Package cups-1.6.3-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-1.6.3-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-12888/cups-1.6.3-1.fc19 then log in and leave karma (feedback).
cups-1.6.3-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.