[Poppler-bugs] [Bug 78714] Pdftoppm "Bogus memory allocation size" with high resolution raster

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78714

--- Comment #3 from Thomas Freitag <Thomas.Freitag at alfa.de> ---
Created attachment 100468
  --> https://bugs.freedesktop.org/attachment.cgi?id=100468&action=edit
allocate intersections in smaller chunks, break if reaching limits

After looking again at the code and thinking a little bit more about it I think
I find now a better solution.
One of the reasons wha we reach the limit in this case is that the number of
intersections is just doubled everytime. So the size of intersections is
increased exponential which is good for "small" pathes because it decreases the
number of reallocations but waste a lot of memory for complex pathes. Therefore
I allocate now only 32768 new intersections if I reach the limit. Now I'm able
to render the pdf up to a resolution of 400 dpi without any problems.
The usage of greallocn_checkoverflow is not possible if we want to paint at
least the path up to the limit we can allocate, because greallocn_checkoverflow
will free the complete memory when limit is reached, so the already constructed
intersections will be freed then and the path cannot be painted at all.
Therefore this patch make the checkoverflow test by its own. This problem will
i.e. reached if the pdf is rendered with 500 dpi now.

Albert, the patch is ready for review. I'll forward the mail from Cory so that
you can check it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20140605/9dbc4daf/attachment.html>