I've got (at least) two documents which make evince with poppler-0.16.3 crash. The stack traces look somewhat similar. (It happened in the cairo backend both times, but since I can't tell whether the underlying bug is there I've filed the report under "general" for now. It looks like some corruption - in one case a dictionary looks strange, a key is -1.) I can make one of the documents available, but since it contains personal data of an unrelated person I'll not attach it here but send it to a developer on request. Here are the stack traces: #0 0x00000008 in ?? () #1 0xb60e2d89 in Gfx::go () from /usr/pkg/lib/libpoppler.so.13 #2 0xb60e4233 in Gfx::display () from /usr/pkg/lib/libpoppler.so.13 #3 0xb662251f in CairoOutputDev::tilingPatternFill () from /usr/pkg/lib/libpoppler-glib.so.6 #4 0xb60ea69c in Gfx::doTilingPatternFill () from /usr/pkg/lib/libpoppler.so.13 #5 0xb60ec09f in Gfx::doPatternFill () from /usr/pkg/lib/libpoppler.so.13 #6 0xb60ec867 in Gfx::opFill () from /usr/pkg/lib/libpoppler.so.13 #7 0xb60e22a6 in Gfx::execOp () from /usr/pkg/lib/libpoppler.so.13 #8 0xb60e2a43 in Gfx::go () from /usr/pkg/lib/libpoppler.so.13 #9 0xb60e4233 in Gfx::display () from /usr/pkg/lib/libpoppler.so.13 #10 0xb61337f3 in Page::displaySlice () from /usr/pkg/lib/libpoppler.so.13 #11 0xb661980d in _poppler_page_render () from /usr/pkg/lib/libpoppler-glib.so.6 #12 0xb66199f1 in poppler_page_render () from /usr/pkg/lib/libpoppler-glib.so.6 #0 0xbad1f542 in strcmp () from /usr/lib/libc.so.12 #1 0xb626f4b7 in Dict::lookupNF () from /usr/pkg/lib/libpoppler.so.13 #2 0xb62835d7 in GfxResources::GfxResources () from /usr/pkg/lib/libpoppler.so.13 #3 0xb62852ab in Gfx::Gfx () from /usr/pkg/lib/libpoppler.so.13 #4 0xb697a510 in CairoOutputDev::tilingPatternFill () from /usr/pkg/lib/libpoppler-glib.so.6 #5 0xb628a69c in Gfx::doTilingPatternFill () from /usr/pkg/lib/libpoppler.so.13 #6 0xb628c09f in Gfx::doPatternFill () from /usr/pkg/lib/libpoppler.so.13 #7 0xb628c7c7 in Gfx::opEOFill () from /usr/pkg/lib/libpoppler.so.13 #8 0xb62822a6 in Gfx::execOp () from /usr/pkg/lib/libpoppler.so.13 #9 0xb6282a43 in Gfx::go () from /usr/pkg/lib/libpoppler.so.13 #10 0xb6284233 in Gfx::display () from /usr/pkg/lib/libpoppler.so.13 #11 0xb62d37f3 in Page::displaySlice () from /usr/pkg/lib/libpoppler.so.13 #12 0xb697180d in _poppler_page_render () from /usr/pkg/lib/libpoppler-glib.so.6 #13 0xb69719f1 in poppler_page_render () from /usr/pkg/lib/libpoppler-glib.so.6
Please send the document, without the document there won't be any fix.
Works fine here, can you attach a valgrind trace of the crash?
There is at least another file (the "AeqB.pdf" text about formal proofs which is available at various places on the net) which makes evince or epdfview crash for me from apparent heap corruption in _render_type3_glyph(). This function and tilingPatternFill have in common that a sub-instance of cairo is created, and a new "Gfx" object, to render some part of the output. (_render_type3_glyph creates a new CairoOutputDev for that purpose while the latter reuses the original one which looks hackish but doesn't seem to cause the problems I'm seeing.) So here might be some recursion problem or so, or a bug in cairo triggered. I'm using 1.10.2 -- did you test with the same version? best regards Matthias ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
Still works for me, poppler 0.16.3, cairo 1.10.2
I've found the reason if the crashes I've seen: It was an inconsistency of the USE_CMS definitions between libpoppler and libpoppler-glib. In NetBSD/pkgsrc, the frontend libraries are built as separate packages, to limit dependencies to the necessary ones, and it was not enforced that --enable/disable-cms was set for either all or none of the components. The layout of the Gfx and GfxColorSpace classes depends on the USE_CMS preprocessor symbol, and now it is also obvious why code was affected which calls back from CairoOutputDev into Gfx. So your code is not to blame, but wouldn't it be possible to use some subclassing to get the nasty #ifdefs out of the class declarations? Also, there might be problems with programs which use libpoppler directly (which you don't like, I know, but since xpdf allowed it and these programs are quite high-profile ones, one has to live with it). For those, it could help to put USE_CMS into poppler-config.h. best regards Matthias ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
Yeah we have several of those defines that could be improved, would you mind closing this bug and opening a separate one about that?
the code is OK, I'll suggest removal of conditionals in class declarations is a separate bug report
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.