Several built-in printer drivers are completely non-functional, as they crash with a floating point exception immediately, independent of the input file and independent whether the input is PostScript or PDF. The drivers are: - bjc880j - lips4 - lips2p - lips3 - lp2000 - escpage - npdl - rpdl Simple Ghostscript calls with these drivers, like these, give a floating point exception immediately: gs -sDEVICE=rpdl -sOutputFile=x /usr/share/cups/data/testprint.ps gs -sDEVICE=rpdl -sOutputFile=x ~/walking-map-portland-1.pdf
Created attachment 4507 [details] testprint.ps PostScript sample file
Created attachment 4508 [details] walking-map-portland-1.pdf PDF sample file
Assigning to Marcos to find the point of regression (they used to work).
Looks like the multi-thread renderer broke this; r8721 is the first revision that fails: r8721 | ray | 2008-05-08 19:18:14 -0700 (Thu, 08 May 2008) | 49 lines This is the "final" merge of the mtrender (multi-threaded clist rendering) branch into the trunk. The default behavior is still the same, i.e., the clist rendering is done in the same thread as the parsing (main thread).
The problem is with devices that use the contrib/lips4/gdevlprn.h header files. The lp_duplex_device_body_rest_ and lp_device_body_rest_ macros that initialized the prn_device structure 'common' elements were out of data with respect to the revision in the gx_device_printer_s structure made for the multi-threaded rendering. I restructured the prn_device_body_rest2_ in base/gdevprn.h so that the contrib/lips4/gdevlprn.h initialization macro could use this to minimize the likelihood of bit rot in the future. I did a search for other devices that might have the same problem and did not find them (although I may have missed them).
patch committed as rev 9192.