Bug 689098 - Memory and CPU problem when converting a specific page in TIFF or PS format
Summary: Memory and CPU problem when converting a specific page in TIFF or PS format
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: 8.54
Hardware: PC Windows 2000
: P3 normal
Assignee: Robin Watts
URL:
Keywords: bountiable
Depends on:
Blocks:
 
Reported: 2007-02-22 02:45 UTC by Jean-Luc Hofman
Modified: 2014-02-17 04:44 UTC (History)
4 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Page causing GhostScript to use increasing memory and to stop (1.07 MB, application/pdf)
2007-02-22 02:48 UTC, Jean-Luc Hofman
Details
screenshot.png (27.39 KB, image/png)
2007-03-20 23:01 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Luc Hofman 2007-02-22 02:45:57 UTC
The page attached to this bug report (p18.pdf) provokes the following problem
with GhostScript, on Windows 2000 and Windows XP :

The command used is :
gswin32c -sOutputFile#p18.tif -I"c:\winnt\fonts" -dNOPAUSE -dBATCH
-sDEVICE#tiffg4 -r300 p18.pdf

The CPU is used at 100% and the memory is being used increasingly, for a long
time, until the program ends with the following message :

AFPL Ghostscript 8.54 (2006-05-17)
Copyright (C) 2005 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
Loading TimesNewRomanPSMT font from c:\winnt\fonts/Times.ttf... 2576176 933929
2451880 1096580 3 done.
Loading ArialMT font from c:\winnt\fonts/Arial.ttf... 2582368 965005 2887916
1469140 3 done.
Loading TrebuchetMS font from c:\winnt\fonts/Trebuc.ttf... 2582368 977413
3454836 2079958 3 done.
Error: /VMerror in --stroke--
VM status: 3 2177334 2295388
Current allocation mode is local
AFPL Ghostscript 8.54: Unrecoverable error, exit code 1

There is no file produced while converting in TIFF.
The conversion to PostScript ends with a file being created, but incomplete.
This output could maybe be used to check the problem.
Comment 1 Jean-Luc Hofman 2007-02-22 02:48:19 UTC
Created attachment 2779 [details]
Page causing GhostScript to use increasing memory and to stop
Comment 2 Francois Donnay 2007-03-01 07:11:55 UTC
Do you have reproduced the problem?

Thanks in advance,
Francois
Comment 3 Francois Donnay 2007-03-19 04:16:27 UTC
Have you any news for us?
Comment 4 Marcos H. Woehrmann 2007-03-20 23:01:07 UTC
Created attachment 2844 [details]
screenshot.png

Adobe Acrobat Reader 7.0 on my 64 bit Linux box fails in a similar way (see
screenshot.png).  It initially loads the PDF okay, but when I try to zoom in it
consumes and more and more memory (I killed it at 2 gigs).
Comment 5 Alex Cherepanov 2007-07-07 05:50:43 UTC
The file contains the following fragment:

[0.075756 0.028408 ] 0 d
-907.772 786.549 m         %  Repeated 128 times
9646.9238 -15043.7656 l    %  with small variations.
S

i.e strokes a dashed line with 32M dashes. No wonder the file needs so
much memory. IMHO the file is invalid.

Comment 6 Ray Johnston 2007-07-07 11:12:47 UTC
Some additional DEBUG (PDFSTEP output):

4 0 0 4 0 0 cm    step # 201335 ?
[    step # 201336 ?
0.075756 0.028408 ]    step # 201337 ?
0 d    step # 201338 ?
-907.772 786.549 m    step # 201339 ?
19646.9238 -15043.7656 l    step # 201340 ?

Then the sequence of 'm' and 'l' repeats as Alex mentions,
then finally the 'killer' processing starts with:

S    step # 201495 ?

_____________________________________________________________

Does it make sense to eaxmine the dash settings and when the entire
dash sequence is less than 2 device pixels, turn it into a solid line ?

Also the order in the graphics library must be converting the entire
line to dashes, even if it is outside the clip path.

At 300 dpi, the dash pattern implied by: [ .075756 .028408 ] is 1.7367
device pixels. At this same scale, the stroke segments deltas are
175911.5 in X and 263838 in Y. The entire page (A4) is only 2480x3508
pixels.

Ignoring dash expansion outside the clip path (accumulating position, but
don't add individual segments to the path) would optimize this somewhat.

______________________________________________________________

With the following (experimental) patch, I was able to convert the file to
tiffg4 at 300 dpi in 23 seconds using less than 10Mb.

*** lib/pdf_draw.ps Thu Jun 21 19:36:18 2007
--- ./pdf_draw.ps Sat Jul  7 11:15:20 2007
***************
*** 287,293 ****

    /i { 1 .min setflat } bdef
    /J /setlinecap load def
!   /d /setdash load def
    /j /setlinejoin load def
    /w /setlinewidth load def
    /M { 1 .max setmiterlimit } bdef
--- 287,298 ----

    /i { 1 .min setflat } bdef
    /J /setlinecap load def
!   /d { 1 index length 0 gt {
!        1 index 0 exch { add } forall
!        dup dtransform pop
!          2 lt { exch pop [ ] exch } if        % set to solid
!        } if setdash
!      } bind def       % /setdash load def
    /j /setlinejoin load def
    /w /setlinewidth load def
    /M { 1 .max setmiterlimit } bdef
_______________________________________________________________________

Ressigning to Igor to consider making the optimizations in the graphics
library where they will benefit PCL as well as PS and PDF.


Comment 7 Ray Johnston 2007-07-07 13:00:12 UTC
Actually, thinking about it a bit more, it probably suffices to treat any
dash pattern with the largest 'space' being less than one pixel since the
'any part of pixel' painting rule will effectively paint all pixels.

Also, the file probably isn't really 'invalid', but probably just a scaled
down version of a map that was intended for rendering much larger.
Comment 8 Ray Johnston 2007-12-11 15:31:21 UTC
Reassigning to Alex for patch review. Graphics library optimizations can
be left to Igor (reassigning the bug back to him then after the consideration
of the patch)
Comment 9 Alex Cherepanov 2011-11-17 05:01:39 UTC
This approach doesn't work because CTM can change between setting the dash
pattern and drawing the line. Testing shows significant regressions.
Comment 10 Ray Johnston 2011-11-17 17:18:48 UTC
OK, so I guess what is needed is to put the logic down in the C code when the
line is drawn (to ignore small dashes that would just be solid anyway).

Thanks, Alex, for pointing out the issue with doing it when 'setdash' is
invoked.
Comment 11 Robin Watts 2011-11-17 18:12:18 UTC
Sounds like a graphics lib issue.
Comment 12 Robin Watts 2013-10-02 11:16:02 UTC
Solved in:

commit dcc172feb018bfe0613f90ce76ce25dd1eafe3ce
Author: Robin Watts <robin.watts@artifex.com>
Date:   Tue Oct 1 17:52:43 2013 +0100

    Bug 689098: Only dash paths when the dashing would be visible.

    If the ctm doesn't expand the dash lengths to be > 1 pixel, then
    they can't be seen, so don't bother.

Many thanks.