Bug 690122 - Floating point exceptions with many built-in printer drivers
Summary: Floating point exceptions with many built-in printer drivers
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Printer Driver (show other bugs)
Version: 8.63
Hardware: PC Linux
: P4 normal
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-15 01:11 UTC by Till Kamppeter
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
testprint.ps (16.96 KB, application/postscript)
2008-10-15 01:13 UTC, Till Kamppeter
Details
walking-map-portland-1.pdf (266.00 KB, application/pdf)
2008-10-15 01:14 UTC, Till Kamppeter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2008-10-15 01:11:42 UTC
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
Comment 1 Till Kamppeter 2008-10-15 01:13:09 UTC
Created attachment 4507 [details]
testprint.ps

PostScript sample file
Comment 2 Till Kamppeter 2008-10-15 01:14:08 UTC
Created attachment 4508 [details]
walking-map-portland-1.pdf

PDF sample file
Comment 3 Ray Johnston 2008-10-16 09:52:51 UTC
Assigning to Marcos to find the point of regression (they used to work).
Comment 4 Marcos H. Woehrmann 2008-10-16 10:34:10 UTC
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).

Comment 5 Ray Johnston 2008-11-02 15:36:50 UTC
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).
Comment 6 Ray Johnston 2008-11-02 20:29:20 UTC
patch committed as rev 9192.