Bug 688113

Summary:	null ptr crash in gdevp14.c
Product:	Ghostscript	Reporter:	Stefan Kemper <stefan.kemper>
Component:	Graphics Library	Assignee:	Dan Coby <dan.coby>
Status:	NOTIFIED FIXED
Severity:	normal
Priority:	P3
Version:	8.51
Hardware:	Other
OS:	Windows 2000
Customer:	770	Word Size:	---

Description Stefan Kemper 2005-05-25 08:06:37 UTC

under Windows 2000/XP
for out software. Under some circumstances
an access violation occurs because of
a reference of a NULL-pointer in gdevp14.c.

This seems to occur if I try to scale PDF-files
with transparent mode and PDF-1.4.

I used the following commands:
-sDEVICE=tiffpack
-r600x600
-g28086x19866
-dMaxBitmap=70000000
-sOutputFile=c:\temp\test.tif

userdict begin
/Install
{
userdict begin
flush (Performing Install) print flush
1.0 1.0 scale
0 0 translate
end
}bind def

end %userdict

<</Install userdict/Install get>> setpagedevice
(F:/test/w21-10-s16-00-02.pdf) run

The problem seems to occur if I use the command
-dMaxBitmap.
If I replace the command -dMaxBitmap=... by the command
-dBufferSpace=64000000
an error occurs as well (devision by zero).

Comment 1 Stefan Kemper 2005-05-25 08:08:11 UTC

Created attachment 1410 [details]
huge cad drawing

Comment 2 Stefan Kemper 2005-05-25 08:09:07 UTC

Created attachment 1411 [details]
large poster

Comment 3 Ray Johnston 2005-05-25 11:28:33 UTC

A simpler way to do this from a command line option would be to put the
following into a file 'gs_args':

-dNOPAUSE
-dBATCH
-sDEVICE=tiffpack
-r600x600
-g28086x19866
-dMaxBitmap=70000000
-dBufferSpace=64000000
-c "<< /Install { (Performing Install) = flush 1.0 1.0 scale 0 0 translate
}bind >> setpagedevice"
-f test.ps

then invoke Ghostscript with:    gswin32c @gs_args

I can confirm the failure, but note that I have debug logic built in and
with these parameters it is trying to allocate a pdf14 buffer with:
pdf14_buf_new, rect [ ( 0, 0 ) , ( 28086, 14562 ) ], n_chan: 4, has_alpha: 0,
@c6c0d0
pdf14_buf_new, planestride = 409017456, n_planes = 4, memsize = 1636069824

Obviously there is a problem when calculating the BandHeight that causes us
to not use a small enough band. If I add:

-dBandHeight=2048

then it uses 10 bands, and the pdf14 buffers are:
pdf14_buf_new, rect [ ( 0, 0 ) , ( 28086, 2048 ) ], n_chan: 4, has_alpha: 0, @c6c1a0
pdf14_buf_new, planestride = 57524224, n_planes = 4, memsize = 230096896

and the file processes to completion in about 80 seconds (DEBUG build on
my 1.3GHz Pentium M with 512Mb RAM).

Comment 4 Ray Johnston 2005-05-25 14:19:55 UTC

Dan wanted this one (mentioned on IRC).

Comment 5 Dan Coby 2005-05-26 23:28:48 UTC

The fix for this problem is described in:

http://ghostscript.com/pipermail/gs-cvs/2005-May/005529.html