Bug 691596 - crash when using png output device with particular pdf input file
Summary: crash when using png output device with particular pdf input file
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: PC All
: P4 critical
Assignee: Ray Johnston
URL:
Keywords:
: 691823 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-06 16:17 UTC by Joseph Heenan
Modified: 2011-07-11 06:09 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
specimen file (18.39 KB, application/pdf)
2010-09-06 16:24 UTC, Ken Sharp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Heenan 2010-09-06 16:17:37 UTC
Original source file:

http://www.owasp.org/images/6/6c/Attacking_WCF_Web_Services-Brian_Holyfield.pdf

Tested with svn r11689 and release 8.71, both affected.

Command line used was:

ghostscript -dSAFER -dBASE -dNOPAUSE -sDEVICE=png16m -r300 -sOutputFile=out-%d.png ~/Attacking_WCF_Web_Services-Brian_Holyfield.pdf 

The problem seems to be a null pointer call - this patch prevents the crash:

Index: base/gxclrast.c
===================================================================
--- base/gxclrast.c	(revision 11689)
+++ base/gxclrast.c	(working copy)
@@ -53,6 +53,7 @@
 #include "gxshade4.h"
 #include "gsicc_manage.h"
 #include "gsicc.h"
+#include "gxdevcli.h"
 
 extern_gx_device_halftone_list();
 extern_gx_image_type_table();
@@ -1994,7 +1995,9 @@
 	    case cmd_op_fill_rect >> 4:
 		if (state.rect.width == 0 && state.rect.height == 0 &&
 		    state.rect.x == 0 && state.rect.y == 0) {
-		    code = (*dev_proc(tdev, fillpage))(tdev, &imager_state, &dev_color);
+		   dev_proc_fillpage((*fillpage));
+		     fillpage = dev_proc(tdev, fillpage);
+		   code = fillpage ? (*fillpage)(tdev, &imager_state, &dev_color) : 0;
 		    break;
 		}
 	    case cmd_op_fill_rect_short >> 4:
Comment 1 Ken Sharp 2010-09-06 16:24:11 UTC
Created attachment 6703 [details]
specimen file

Much reduced and decompressed example file. The file contains a single image XObject, and several inline images in an Indexed RGB space which resolve to pretty much entirely white.

There seems to be no other complexity to speak of, but reducing the file further in Acrobat causes it to work....
Comment 2 Ken Sharp 2010-09-06 16:43:53 UTC
We seem to encounter a 0 height and width rectangular fill, at x=y=0 during the course of a clip accumulation. A 0 width and height rectangle at 0,0 is special cased as a fillpage, but the clip accumulator doesn't have a fillpage method, so a crash ensues.

This could be fixed by:

1) Not writing bogus fill rectangles.

2) Adding a fillpage method to the clip accumulator

3) Testing the fillpage method to see if its NULL before using it.

Or, of course, I could be barking up completely the wrong tree, this not being my area of code.

Probably this should go to Ray.
Comment 3 Ray Johnston 2010-09-06 17:19:31 UTC
I agree that this needs to be straigtened out in the clist logic (the writing
logic, probably). I'll have a look at it, but probably Ken's option 1 is
the best -- not writing 0-size rectangles is the best. I don't really like
the kloodge for the 'fillpage' case and may make that a unique direct function
instead.
Comment 4 Alex Cherepanov 2011-01-02 02:58:22 UTC
*** Bug 691823 has been marked as a duplicate of this bug. ***
Comment 5 Ray Johnston 2011-01-06 20:12:44 UTC
BTW, this didn't fail for me at 300 dpi, but did at 600.

The problem is caused by a clip region that is empty (a 0 width, 0 height rect).

The 'tdev' when the clist reader gets a 'fill_rect' command is the clip_list_
accumulator, which understandably does not have a fillpage proc since all it
is trying to do is to accumulate the pieces of the clip region.

Ordinarily, these 0 width, 0 height rectangles would be written using the
'fill_rect_tiny' operation code (0x5c) rather that the 'fill_rect' opcode
(0x30), so we wouldn't trip over the "special" (hacky) logic in fill_rect
that interprets a 0 width, 0 height rectangle as 'fillpage'.

The fix proposed will work, and is safe, so I will commit it, but also will
look at why the logic that is writing the empty clip path is sometimes 
(rarely) using the fill_rect rather than fill_rect_tiny opcode. Note that
in the sequence following the problematic opcode, we see:

L]begin_clip(offset=53080):
L]fill_rect_tiny 12(offset=53081): x=0 y=0 w=0 h=0
L]end_clip(offset=53082):

Thus in another adjacent case, the clip path writing _is_ using the short
form fill_rect_tiny opcode.
Comment 6 Ray Johnston 2011-07-11 06:09:49 UTC
This was fixed by Robin's patch -- the "real" fix for fillpage is not needed
urgently, just a cleanup.