[gs-bugs] [Bug 691596] crash when using png output device with particular pdf input file

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Thu Jan 6 20:12:50 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=691596

--- Comment #5 from Ray Johnston <ray.johnston at artifex.com> 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.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list