Created attachment 103241 [details] PDF Test case This was reported in GNOME's Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=733402 pdftocairo crashes when trying to render the attached document. FWIW, an older version of poppler (0.18.)0 does not have this issue. My cairo version is 2a7f133639 (>0.12.16). The stacktrace is as follows: (gdb) r -png ~/Descargas/epiphany/013-crash.pdf Starting program: /home/gpoo/code/evince/install/bin/pdftocairo -png ~/Descargas/epiphany/013-crash.pdf [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x08053080 in CairoOutputDev::endTransparencyGroup (this=0x8087178) at CairoOutputDev.cc:1500 1500 if (groupColorSpaceStack->next && groupColorSpaceStack->next->knockout) { (gdb) thread apply all bt Thread 1 (Thread 0xb74c2800 (LWP 3911)): #0 0x08053080 in CairoOutputDev::endTransparencyGroup (this=0x8087178) at CairoOutputDev.cc:1500 #1 0x0805124a in CairoOutputDev::unsetSoftMaskFromImageMask (this=0x8087178, state=0x8244d48, baseMatrix=0x80879b4) at CairoOutputDev.cc:1932 #2 0xb7e6a120 in Gfx::doPatternImageMask (this=0x8087978, ref=0xbfffe0a4, str=0x8246378, width=1, height=1, invert=false, inlineImg=false) at Gfx.cc:2097 #3 0xb7e6b2bc in Gfx::doImage (this=0x8087978, ref=0xbfffe0a4, str=0x8246378, inlineImg=false) at Gfx.cc:4370 #4 0xb7e703f1 in Gfx::opXObject (this=0x8087978, args=0xbfffe184, numArgs=1) at Gfx.cc:4179 #5 0xb7e5f949 in Gfx::execOp (this=0x8087978, cmd=0xbfffe324, args=0xbfffe184, numArgs=1) at Gfx.cc:903 #6 0xb7e670b0 in Gfx::go (this=0x8087978, topLevel=true) at Gfx.cc:762 #7 0xb7e6756e in Gfx::display (this=0x8087978, obj=0xbfffe414, topLevel=true) at Gfx.cc:728 #8 0xb7eb3873 in Page::displaySlice (this=0x8087da0, out=0x8087178, hDPI=72, vDPI=72, rotate=0, useMediaBox=true, crop=false, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=false, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0, copyXRef=false) at Page.cc:585 #9 0xb7ebc815 in PDFDoc::displayPageSlice (this=0x8087570, out=0x8087178, page=1, hDPI=72, vDPI=72, rotate=0, useMediaBox=true, crop=false, printing=false, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0, copyXRef=false) at PDFDoc.cc:503 #10 0x0804f4c6 in renderPage (output_h=3367, output_w=2363, page_h=1615.75, page_w=1133.8599850000001, pg=1, cairoOut=0x8087178, doc=0x8087570) at pdftocairo.cc:588 #11 main (argc=2, argv=0xbfffe6c4) at pdftocairo.cc:1056
The crash was introduced in c40e2315. The problem is that when entering the cairo work around in CairoOutputDev::setSoftMaskFromImageMask() we return early without creating the transparency group, but CairoOutputDev::unsetSoftMaskFromImageMask() assumes the transparency group is always created. Checking groupColorSpaceStack in unsetSoftMaskFromImageMask to return early fixes the issue, but I'm not sure that's the best way to check whether we are in a transparency group or not.
Created attachment 103391 [details] [review] Patch I think it would be better to ensure we always push a transparency group.
No regressions in my test suite with this patch, so pushed to both branches.
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.