Bug 25189 - division by zero in Gfx::doAxialShFill
Summary: division by zero in Gfx::doAxialShFill
Alias: None
Product: poppler
Classification: Unclassified
Component: cairo backend (show other bugs)
Version: unspecified
Hardware: All NetBSD
: medium major
Assignee: poppler-bugs
QA Contact:
Depends on:
Reported: 2009-11-19 10:15 UTC by M.Drochner
Modified: 2018-08-20 21:46 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

patch to avoid division-by-zero (1.07 KB, patch)
2009-11-19 10:15 UTC, M.Drochner
Details | Splinter Review
new patch (559 bytes, patch)
2009-11-20 06:52 UTC, M.Drochner
Details | Splinter Review
better patch (1.60 KB, patch)
2009-11-20 08:04 UTC, M.Drochner
Details | Splinter Review

Description M.Drochner 2009-11-19 10:15:09 UTC
Created attachment 31318 [details] [review]
patch to avoid division-by-zero

A PDF document (which I can make available but which is too large to post here)
could be viewed in "evince" but when I tried to print it the resulting PDF
was invalid. It turned out that it contained "nan" literally in linear shade
objects where numbers are expected.
The NaNs were originating from poppler's Gfx::doAxialShFill function. Both
tMin and tMax are zero in that situation (as was dy; dx was non-zero).
For now, I've using the appended patch to work around the problem.
(It seems to me that problem is in the intersection code but I didn't
look deeper yet.)
Comment 1 M.Drochner 2009-11-19 10:37:23 UTC
after a second look at my patch: substituting by tMin doesn't look correct --
if at all, a zero should be passed. But cairo clips the value anyway
(just NaN slips through), so this is not a major issue.
Comment 2 Albert Astals Cid 2009-11-19 11:35:36 UTC
Please send me or add an URL to the document
Comment 3 M.Drochner 2009-11-19 11:49:38 UTC
> Please send me or add an URL to the document
just did so per PM, please tell me if it doesn't arrive
Comment 4 Albert Astals Cid 2009-11-19 14:25:16 UTC
CairoOutputDev problem as it's the only one using useFillColorStop. Carlos?
Comment 5 M.Drochner 2009-11-20 06:51:23 UTC
The problem is not the intersection code but a somewhat arbitrary test that
prevents it from being used: dx is non-zero but less than 0.01 where the
problem occurs. So dxZero gets set unnecessarily.
My impression is that a axial shading with both "Coords" set to exactly
the same value is invalid, so why not bail out completely in that case?
I'll append a new patch which removes the problematic test, but does not
reject the "dxZero && dyZero" case yet -- perhaps I've missed some clause
in the PDF spec. With that patch, everything works well for me.
Comment 6 M.Drochner 2009-11-20 06:52:04 UTC
Created attachment 31342 [details] [review]
new patch
Comment 7 M.Drochner 2009-11-20 08:04:14 UTC
Created attachment 31344 [details] [review]
better patch

I've redone the patch slightly, to take into account the possibility that
a multiplication can hit the numerical limits. Even if it can't happen
in practice it looks more logical to me.
Comment 8 GitLab Migration User 2018-08-20 21:46:32 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/62.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.