Bug 689781 - Crash or rangecheck of tiffsep device at specific PageSizes & Resolution
Summary: Crash or rangecheck of tiffsep device at specific PageSizes & Resolution
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Other Driver (show other bugs)
Version: master
Hardware: PC Windows XP
: P4 critical
Assignee: Ray Johnston
URL:
Keywords: bountiable
Depends on:
Blocks:
 
Reported: 2008-04-04 04:26 UTC by claentzsch
Modified: 2012-04-16 03:11 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Patch for bug 689781 (577 bytes, patch)
2011-07-24 03:57 UTC, wendyst2
Details | Diff
Regenerated patch for 689781 (719 bytes, application/vnd.ms-excel)
2011-07-24 13:49 UTC, wendyst2
Details
Patch for 689781 Revision 2 (968 bytes, application/vnd.ms-excel)
2011-07-24 16:55 UTC, wendyst2
Details

Note You need to log in before you can comment on or make changes to this bug.
Description claentzsch 2008-04-04 04:26:54 UTC
Using tiffsep device with specific PageSizes and resolutions leads to Crash or 
rangecheck error.

Consider following PS code:

<< /PageSize [1670 1158] >> setpagedevice
.5 setgray
clippath fill
showpage

Set resolution to 1200x1200 DPI (-r1200x1200) and -sDEVICE=tiffsep
Result:
In gs-HEAD you get a rangecheck error in showpage.
Pre-Head, like 8.54:
CRASH in mem_true64_fill_rectangle() (at the very beginning) while filling 
rectangle. I guess, only one band of memory should be erased at this time, but 
the coordinates are set for the whole image (in this case: very big).

Vary the PageSize parameters or resolution a little and it works!
This makes me unhappy, because depending on the size of input document, GS 
fails.
Comment 1 Marcos H. Woehrmann 2008-04-06 17:56:11 UTC
I've verified that this occurs with gshead and tiffsep but not with the bmpsep1 or bmpsep8 devices, so am 
assigning it accordingly.
Comment 2 Ray Johnston 2008-04-17 10:17:25 UTC
The tiffsep device (like the tiff32nc and tiff24nc devices) creates uncompressed
tiff image files. TIFF is an older format and does not support 64 bit values for
offsets and lengths, so this PageSize is too large to fit at 1200 dpi.

This PageSize works out to be 2148707600 bytes which is too large.

To handle larger page sizes, the TIFF would have to use compression, which is an
enhancement.
Comment 3 Alex Cherepanov 2008-04-17 14:14:08 UTC
I think TIFF has unsigned offsets and should support about 4GB of data.
We hit 2GB limit because we use old file access functions.
Comment 4 James Cloos 2010-05-15 22:30:19 UTC
What exactly is needed to collect on this?

Tiff compression?

Ensure the use of unsigned values for offsets and the like?

Both?

Neither? ☺
Comment 5 James Cloos 2011-06-11 22:03:52 UTC
Today’s master (64bit lang switch build) finishes that ps w/o error.

The plate tiffs are LZW compressed.  The combined tiff is not.

I haven’t tested a 32 bit compile, but at least for 64 bit compiles this seems fixed?
Comment 6 wendyst2 2011-07-24 03:57:45 UTC
Created attachment 7705 [details]
Patch for bug 689781
Comment 7 wendyst2 2011-07-24 03:59:46 UTC
The composite TIFF with the given page size and resolution happens to be between 2GB and 4GB. Submitted a patch to fix this.
Comment 8 wendyst2 2011-07-24 13:49:58 UTC
Created attachment 7710 [details]
Regenerated patch for 689781
Comment 9 Ray Johnston 2011-07-24 14:45:08 UTC
I'm not sure how it could happen, but if the file size ever exceeded 0xffffffff
then the truncation of 0xffffffff - gp_ftell_64 would give an incorrect result
with the patch in comment 8. To be totally sure, a separate check for int64_t
file size > 0xffffffff should be included to trigger the rangecheck.
Comment 10 wendyst2 2011-07-24 16:55:41 UTC
Created attachment 7711 [details]
Patch for 689781 Revision 2

Can not reproduce the error on Windows as described in comment 9 (getting "range check" error as expected for 2400 dpi). But submitted a revised patch.
Comment 11 Alex Cherepanov 2012-04-16 03:11:05 UTC
Ghostscript uses libTiff now, which handles files that exceed 2GB correctly.
libTiff also detects when TIFF file exceeds 4GB and propagates this
condition to PostScript level.

Everything seems to work just fine now.