Created attachment 7959 [details] firefox-gs-crash-lp864509.pdf See https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/864509 The user is trying to print http://www.ednes.com/gaz/index.php?option=com_content&task=view&id=29&Itemid=47 out of Firefox 7.01 on Ubuntu Oneiric, clicking the printer icon at the upper right of the page and clicking the printer icon at the upper right of the preview pop-up again. Firefox sends a PDF file to CUPS and Ghostscript 9.04 then renders this PDF to CUPS Raster for an HP inkjet. Color space is RGBW. To reproduce, the PDF file sent by Firefox is attached. The Ghostscript command line is the following: /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -sMediaType=Plain -sOutputType=0 -r600x600 -dMediaPosition=7 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=832 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=17 -dcupsInteger0=26 -scupsPageSizeName=A4 -I/usr/share/cups/fonts -c -f firefox-gs-crash-lp864509.pdf > out.raster This simplified command line shows the same failure: /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -r600x600 -dcupsBitsPerColor=8 -dcupsColorSpace=17 firefox-gs-crash-lp864509.pdf > out.raster With color space set to 1 the problem does not occur.
Created attachment 7960 [details] log.txt Standard error output of the failing Ghostscript
Displaying the PDF file on the screen with Ghostscript, Poppler or Adobe Reader works without problems.
This looks like a problem in the clist, and its 'probably' caused by the CUPS RGBW colour space somehow (see the last line of comment #0). So I'm moving the assignment to Michael rather than Alex, though in the end it may need input from Ray as well.
This is in the clist -- probably an issue with the color space depth being wrong. The transparency code changes the color space as required for the current transparency group and if the depth is wrong, then the clist gets confused this way. I reproduced this on Windows using: gswin32c -r600 -sDEVICE=cups -o nul: -dcupsColorSpace=17 Bug692568.pdf If I have time, I'll add more specific debug info on this.
Simplified Linux command line: gs -sOutputFile=/dev/null -sDEVICE=cups -r600x600 -dcupsColorSpace=17 firefox-gs-crash-lp864509.pdf >log.txt 2>&1
I've determined that the pdf14 device is being set for RGB (which is correct), but the clist 'cmd_put_color' uses clist_color_info.depth to decide how many bytes to write and this is 32, not 24 as expected when reading the clist back into the pdf14 RGB device (the reader uses tdev->color_info.depth). I think that the c_pdf14trans_clist_write_update needs to properly set the clist_color_info using the p14dev->color_info (particularly the depth). Note that this means that the code to check that the clist_color_info.depth is for 8 bits per component is not needed if we set it to value from the pdf14dev (since this is always 8 bits per component). I tried a patch and got a LOT of segfaults, so I am looking further to see why this might be.
I found (as I was discussing it with Michael V over the phone) the problem with my previous patch -- I had gotten overzealous and deleted an assignment that caused the bunch of segfaults. With that assignment restored, the cluster test looks good.
Your committed patch d5f1e72 on GIT works. The bug seems to be fixed now. Thank you very much.