Bug 691170

Summary:	Some PDFs make GS segfault with small space_params->MaxBitmap others with large space_params->MaxBitmap
Product:	Ghostscript	Reporter:	Till Kamppeter <till.kamppeter>
Component:	PDF Interpreter	Assignee:	Ray Johnston <ray.johnston>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P4
Version:	8.71
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---
Attachments:	R220.ppd EntryConditions-evince.pdf CityMap-evince.pdf

Description Till Kamppeter 2010-03-11 18:58:51 UTC

Attached are two PDF files and a PPD file. One of the PDF files (EntryConditions-evince.pdf) only renders if the space_params->MaxBitmap value is 64 MB or smaller (including 0) and segfaults if the value is 128 MB or bigger.  The other PDF file (CityMap-evince.pdf) renders with space_params->MaxBitmap being 512MB or bigger and segfaults with 256MB or smaller (including 0).

Here are the command lines to reproduce the problem. Note that with the RIP_MAX_CACHE environment variable the CUPS Raster output device sets space_params->MaxBitmap (it sets also space_params->BufferSpace but I get the same results if I comment out this setting). The segfaults happen somewhere in the rendering code, not in the CUPS Raster output device.

EntryConditions-evince.pdf, small space_params->BufferSpace -> OK:

cat ~/ghostscript/gpl/testfiles/EntryConditions-evince.pdf | PPD=/etc/cups/ppd/R220.ppd RIP_MAX_CACHE=64m /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -sMediaClass=Standard -sMediaType=Plain -r720x360 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsRowFeed=5 -scupsPageSizeName=A4 -c -f -_ > out.raster 2>log

EntryConditions-evince.pdf, large space_params->BufferSpace -> segfault:

cat ~/ghostscript/gpl/testfiles/EntryConditions-evince.pdf | PPD=/etc/cups/ppd/R220.ppd RIP_MAX_CACHE=128m /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -sMediaClass=Standard -sMediaType=Plain -r720x360 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsRowFeed=5 -scupsPageSizeName=A4 -c -f -_ > out.raster 2>log

CityMap-evince.pdf, small space_params->BufferSpace -> segfault:

cat ~/ghostscript/gpl/testfiles/CityMap-evince.pdf | PPD=/etc/cups/ppd/R220.ppd RIP_MAX_CACHE=256m /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -sMediaClass=Standard -sMediaType=Plain -r720x360 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsRowFeed=5 -scupsPageSizeName=A4 -c -f -_ > out.raster 2>log

CityMap-evince.pdf, large space_params->BufferSpace -> rangecheck error:

cat ~/ghostscript/gpl/testfiles/CityMap-evince.pdf | PPD=/etc/cups/ppd/R220.ppd RIP_MAX_CACHE=512m /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -sMediaClass=Standard -sMediaType=Plain -r720x360 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsRowFeed=5 -scupsPageSizeName=A4 -c -f -_ > out.raster 2>log

Error: /rangecheck in --run--
Operand stack:
   (/tmp/gs_7Ck1eG)   --nostringval--   --dict:7/16(L)--   3   11
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1878   1   3   %oparray_pop   1877   1   3   %oparray_pop   1861   1   3   %oparray_pop   --nostringval--   --nostringval--   --nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   false   1   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1165/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--   --dict:75/200(L)--   --dict:108/127(ro)(G)--   --dict:288/300(ro)(G)--   --dict:22/25(L)--   --dict:6/8(L)--   --dict:21/40(L)--   --dict:1/1(ro)(G)--   --dict:5/5(L)--   --dict:1/1(ro)(G)--

Comment 1 Till Kamppeter 2010-03-11 19:00:26 UTC

Created attachment 6050 [details]
R220.ppd

PPD file for the sample command lines.

Comment 2 Till Kamppeter 2010-03-11 19:03:10 UTC

Created attachment 6051 [details]
EntryConditions-evince.pdf

PDF file which segfaults on big space_params->MaxBitmap.

Comment 3 Till Kamppeter 2010-03-11 19:04:37 UTC

Created attachment 6052 [details]
CityMap-evince.pdf

PDF file which segfaults on small space_params->MaxBitmap.

Comment 4 Till Kamppeter 2010-03-11 19:07:19 UTC

Note that the thresholds of space_params->MaxBitmap for getting a segfault or not can depend on the hardware, architecture, and operating system. I have done all tests only on 64-bit Intel under 64-bit Linux (Ubuntu Lucid). Ghostscript is built as shared library (libgs).

Comment 5 Ray Johnston 2010-03-11 19:21:52 UTC

Since MaxBitmap controls the internal decision to use the clist banding or not, I'll take this and attempt to duplicate it on my 64-bit ubuntu machine (peeves, an Intel i7 machine w/ 6Gb RAM).

If the case that fails with a LARGE MaxBitmap is non clist related, I may break this into separate bugs and assign to an appropriate engineer.

Comment 6 Till Kamppeter 2010-03-11 20:05:33 UTC

Is space_params->MaxBitmap=0 (and also space_params->BufferSpace=0) meaning zero or unlimited?

Comment 7 Till Kamppeter 2010-03-17 11:34:16 UTC

Ubuntu bug report for this bug:

https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/534525

Comment 8 Till Kamppeter 2010-03-17 11:38:06 UTC

The CityMap.pdf file is from bug #691014.

Comment 9 Hin-Tak Leung 2010-03-23 01:18:25 UTC

Hmm, Till, I just saw the commit message on #irc and wondered what clean-up is done... I think doing exit(1) within a driver is a bit frown upon. (although we all do it from time to time...) - does pstoraster actually use the exit value of the ghostscript process? Even if it does, "return GS_error;" or one of the other things I have seen elsewhere is preferred and probably will set the exit value of the gs process also... I'd let others comment on what's the preferred approach - but I am pretty sure I have not seen any other driver in gs doing exit() within a driver method.

Comment 10 Till Kamppeter 2010-03-23 07:38:06 UTC

I have seen that gs_exit() frees all memory and closes the rendering process but does not close Ghostscript. Mike Sweet probably did not realize it because he did not have any offending input file which made his driver run into the gs_exit() calls. So I added "exit(1)" to each of the gs_exit() calls and this eliminated the segfaults which were caused by the driver going on working on the data structures which were freed by gs_exit(). Now the segfaults are eliminated but not the incapacity of the driver to render the offending files.

Hin-Tak, can you tell me how to replace the sequence "gs_exit(); exit(1)" so that Ghostscript gets correctly shut down in case of an error?

Comment 11 Till Kamppeter 2010-03-23 09:08:11 UTC

Hin-Tak, problem solved. I have found out how to error out correctly. The corrected gdevcups.c is committed now.

This solves the bug of segfaults reported here and with forcing banding mode in addition the file EntryConditions-evince.pdf gets rendered correctly. The problem of CityMap-evince.pdfbug is most probably bug #691014. So I close this bug as fixed.

Comment 12 Hin-Tak Leung 2010-03-23 16:01:04 UTC

I see you have found the answer - in general, driver routines should not exit() but return an error status to the caller (which would then dealt with the error status accordingly).