[gs-bugs] [Bug 691407] Division by 0 in gxfdrop.c:margin_boundary()

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Thu Jul 8 15:29:25 UTC 2010


Robin Watts <robin.watts at artifex.com> changed:

           What    |Removed                     |Added
                 CC|                            |robin.watts at artifex.com

--- Comment #4 from Robin Watts <robin.watts at artifex.com> 2010-07-08 15:29:22 UTC ---
In the latest version of ghostscript, we use freetype to do font rendering by
default; as such the code in gxfdrop.c is not called, hence the problem cannot
easily be reproduced.

Dropping back to use gs8.71 with the supplied file (that I will attach to this
bug in a moment), with the following command line:

debugbin\gswin32c.exe -P- -dBATCH -dNOPAUSE -Z: -r7.2483221x7.2483221
-dFirstPage=1 -dLastPage=1 -dUseCropBox -d.IgnoreNumCopies=true -c (56957.pdf)

we do indeed get a division by 0 at line 279 of gxfdrop.c in the Y_AT_X macro.

In normal use it seems that the division by zero is ignored and the program
continues regardless.

It seems the margin_boundary code can be called with alp being a vertical line,
hence alp->diff.x == 0. The attempt to calculate Y_AT_X therefore fails.

The customer has suggested a fix for this whereby we detect alp->diff.x == 0
and drop out of this routine. That certainly works, and has the benefit of

It is interesting to note that the code can be called with 'alp == 0'
(indicating that the line is horizontal), and that the loop is at pains to cope
with this. For symmetry, should we be handling vertical lines in the same way?
If so, the correct fix would be to alter the conditional setting of y in the
loop so that the Y_AT_X macro is not called in the case when alp.diff.x == 0.

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