Bug 689186

Summary:	PDF segfaults or exits with no output
Product:	Ghostscript	Reporter:	Ray Johnston <ray.johnston>
Component:	Graphics Library	Assignee:	leonardo <leonardo>
Status:	NOTIFIED FIXED
Severity:	normal
Priority:	P2
Version:	master
Hardware:	All
OS:	All
Customer:	770	Word Size:	---
Attachments:	patch.txt patch.txt patch.txt

Description Ray Johnston 2007-04-18 17:45:22 UTC

The customer reports:
The Pdf files causes some problems in the case
one tries to convert the file into a pcx or tiff-file
with larger dpi (approx. greater than 400).
 
For the case -r400x400 and -sDEVICE= tiffpack
a range check error occurs.
For the case -r400x400 and -sDEVICE=pcx24b
even some access violation occur in our application.

With HEAD (r7864) and the tiffpack device I see a 3Gb clist file created (this
takes quite a while), then it exits without generating any output.

-dNOTRANSPARENCY runs in 20 seconds (tiffpack -r400).

Comment 1 Ray Johnston 2007-04-18 17:49:54 UTC

Created attachment 2898 [details]
PDF_mit-mehreren_Ebenen.pdf

Warning -- this is a 7Mb file

Comment 2 Timothy Osborn 2007-04-19 13:12:18 UTC

I'm not seeing the same results here. When I run this with NOTRANSPARENCY and
tiffpack it still takes approximately 7 minutes. This was run with the following
command on peeves:

time ./bin/gs -sDEVICE=tiffpack -r400x400 -dNOTRANSPARENCY -o
DF_mit-mehreren_Ebenen.tif -I./lib ~/PDF_mit-mehreren_Ebenen.pdf
GPL Ghostscript SVN PRE-RELEASE 8.57 (2007-03-15)
Copyright (C) 2007 artofcode LLC, Benicia, CA.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1

real    7m17.582s
user    6m48.010s
sys     0m14.000s

Comment 3 Ray Johnston 2007-04-24 10:04:11 UTC

The memory based clist compresses to <700 Mb. 64 bit offsets _should_ work here.  
This might be a workaround.  
  
The clist code needs checking for offsets past the 2Gb limit when we don't have 64-bit  
file access. 
 
Assigning to Igor to fix the limit checking and to investigate WHY the clist is so BIG.

Comment 4 leonardo 2007-07-17 12:39:33 UTC

It is a slightly rotated b&w image. The rotation tan is about 1/50. The 
graphics library converts it into lots of fill_parallelograms, then the clist 
writer converts them into lots fill_path,
each ow which is a 4-segment path.

Comment 5 leonardo 2007-07-30 23:41:59 UTC

Created attachment 3244 [details]
patch.txt

A suggested patch. It had passed a local regression test with comparefiles at
300 dpi.

Comment 6 leonardo 2007-08-01 11:41:30 UTC

Created attachment 3249 [details]
patch.txt

Same patch with improved log message.

Comment 7 leonardo 2007-08-02 00:45:19 UTC

Now I see the patch is not fully correct. When running decompr-Bug688631-.pdf, 
the 2nd shading paints to the clist writer, which at that moment has color_info 
with 3 color components, and procs.get_color_mapping_procs returns 
DeviceGray_procs. Thus get_color_mapping_procs does not match to color_info. It 
is easy to find with setting a breakpoint into pdf14_cmap_cmyk_direct. The 1st 
passing this breakpoint shows the mismatch. Will attach the test file.

Comment 8 leonardo 2007-08-02 00:47:19 UTC

Created attachment 3251 [details]
decompr-Bug688631-.pdf

A test case for the last comment.

Comment 9 leonardo 2007-08-02 01:28:43 UTC

Created attachment 3252 [details]
patch.txt

An improved patch.

Comment 10 leonardo 2007-08-02 02:08:42 UTC

The last patch has been committed to HEAD as
http://ghostscript.com/pipermail/gs-cvs/2007-August/007750.html