pdf2swf which is part of swftools is segfaulting with jpeg-8 (:0). This program should have DEPEND on jpeg:7 or jpeg:62 Reproducible: Always Steps to Reproduce: 1. emerge jpeg-8 2. emerge swftools 3. run pdf2wsf Actual Results: segfault Expected Results: normal running
No, :62 and :7 are for binary-only programs. Fix to this might be same as for cinelerra, mjpegtools, transcode or xawtv... adding the author of those patches to CC list, maybe he can help ;-)
Also post `emerge --info` and gdb backtrace[1] from pdf2swf segfault. [1] http://www.gentoo.org/proj/en/qa/backtraces.xml
Have you tried jpeg-8a? The report here http://bugs.archlinux.org/task/18201 suggests it might only occur with 8.
Created attachment 224211 [details] PDF in which it crashes on Ok, here's the backtrace: Core was generated by `pdf2swf Untitled.pdf'. Program terminated with signal 11, Segmentation fault. #0 0xb77b46e4 in emit_dqt (cinfo=0xa08f4d4, index=0) at jcmarker.c:158 #1 0xb77b5062 in write_tables_only (cinfo=0xa08f4d4) at jcmarker.c:640 #2 0xb77ad886 in jpeg_write_tables (cinfo=0xa08f4d4) at jcapimin.c:267 #3 0x080598b6 in swf_SetJPEGBitsStart (t=0xa08cdb0, width=400, height=400, quality=85) at modules/swfbits.c:243 #4 0x08059ddb in swf_SetJPEGBits2 (tag=0xa08cdb0, width=400, height=400, bitmap=0xb720a008, quality=85) at modules/swfbits.c:282 #5 0x08067ac2 in swf_AddImage (tag=0xa07b710, bitid=<value optimized out>, mem=0xb720a008, width=168359124, height=<value optimized out>, quality=85) at modules/swfbits.c:1145 #6 0x0810da47 in add_image (dev=0xbf8b27b0, line=0xbf8b120c, img=0xbf8b1234, matrix=0xbf8b1138, cxform=0x0) at devices/swf.c:1930 #7 swf_fillbitmap (dev=0xbf8b27b0, line=0xbf8b120c, img=0xbf8b1234, matrix=0xbf8b1138, cxform=0x0) at devices/swf.c:1976 #8 0x080e9b86 in drawimage (dev=0xbf8b27b0, data=0x0, sizex=400, sizey=400, x1=91.924999999999997, y1=72, x2=91.924999999999997, y2=168, x3=187.92500000000001, y3=168, x4=3758.5, y4=1440, type=0) at GFXOutputDev.cc:2063 #9 0x080ee578 in GFXOutputDev::drawGeneralImage (this=0xa087a90, state=0xa08c848, ref=0xbf8b1b8c, str=0xa08d180, width=400, height=400, colorMap=0xa08e148, invert=0, inlineImg=0, mask=0, maskColors=0x0, maskStr=0x0, maskWidth=0, maskHeight=0, maskInvert=0, maskColorMap=0x0) at GFXOutputDev.cc:2263 #10 0x080eed69 in GFXOutputDev::drawImage (this=0xa087a90, state=0xa08c848, ref=0xbf8b1b8c, str=0xa08d180, width=400, height=400, colorMap=0xa08e148, maskColors=0x0, inlineImg=0) at GFXOutputDev.cc:2348 #11 0x080b5f3c in Gfx::doImage (this=0xa087620, ref=0xbf8b1b8c, str=0xa08d180, inlineImg=0) at xpdf/Gfx.cc:3661 #12 0x080bccfe in Gfx::opXObject (this=0xa087620, args=0xbf8b1c54, numArgs=1) at xpdf/Gfx.cc:3334 #13 0x080b71a1 in Gfx::execOp (this=0xa087620, cmd=0xbf8b1de0, args=0xbf8b1c54, numArgs=1) at xpdf/Gfx.cc:694 #14 0x080b73e1 in Gfx::go (this=0xa087620, topLevel=0) at xpdf/Gfx.cc:585 #15 0x080b7722 in Gfx::display (this=0xa087620, obj=0xbf8b2040, topLevel=0) at xpdf/Gfx.cc:557 #16 0x080bc443 in Gfx::doForm1 (this=0xa087620, str=0xbf8b2040, resDict=0xa08bd50, matrix=0xbf8b1f40, bbox=0xbf8b1f70, transpGroup=0, softMask=0, blendingColorSpace=0x0, isolated=0, knockout=0, alpha=0, transferFunc=0x0, backdropColor=0x0) at xpdf/Gfx.cc:3839 #17 0x080bc829 in Gfx::doForm (this=0xa087620, str=0xbf8b2040) at xpdf/Gfx.cc:3767 #18 0x080bcbfa in Gfx::opXObject (this=0xa087620, args=0xbf8b20e4, numArgs=1) at xpdf/Gfx.cc:3342 #19 0x080b71a1 in Gfx::execOp (this=0xa087620, cmd=0xbf8b2270, args=0xbf8b20e4, numArgs=1) at xpdf/Gfx.cc:694 #20 0x080b73e1 in Gfx::go (this=0xa087620, topLevel=1) at xpdf/Gfx.cc:585 #21 0x080b7722 in Gfx::display (this=0xa087620, obj=0xbf8b235c, topLevel=1) at xpdf/Gfx.cc:557 #22 0x080aa7c3 in Page::displaySlice (this=0xa07b790, out=0xa087a90, hDPI=72, vDPI=72, rotate=0, useMediaBox=1, crop=1, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=1, catalog=0xa07e9d0, abortCheckCbk=0, abortCheckCbkData=0x0) at xpdf/Page.cc:330 #23 0x080aaaba in Page::display (this=0xa07b790, out=0xa087a90, hDPI=72, vDPI=72, rotate=0, useMediaBox=1, crop=1, printing=1, catalog=0xa07e9d0, abortCheckCbk=0, abortCheckCbkData=0x0) at xpdf/Page.cc:279 #24 0x0807f31f in PDFDoc::displayPage (this=0xa07b230, out=0xa087a90, page=1, hDPI=72, vDPI=72, rotate=0, useMediaBox=1, crop=1, printing=1, abortCheckCbk=0, abortCheckCbkData=0x0) at xpdf/PDFDoc.cc:319 #25 0x0807c206 in render2 (page=0xa0875f0, output=0xbf8b27b0) at pdf.cc:89 #26 0x0807c33f in pdfpage_rendersection (page=0xa0875f0, output=0xbf8b27b0, x=0, y=0, _x1=0, _y1=0, _x2=612, _y2=792) at pdf.cc:112 #27 0x08050138 in main (argn=2, argv=0xbf8b28d4) at pdf2swf.c:661
Its unrelated to the problem described in bug 293919. This program neither calls cinfo.raw_data_out nor cinfo.raw_data_im. Also note swftools is not the only program which has this problem, with jpeg-8 so does ImageMagick (stack dump ends the same), which also fixed with jpeg-8a . From the jpeg-8a changelog: Writing tables-only datastreams via jpeg_write_tables works again. So it appears this programs (and ImageMagick, and others) were relying on this functionality which was broken in jpeg-8 and fixed in 8a.
Thanks, the backtrace surely looks like jpeg_write_tables crash... same as in xsane. See bug 310211 (jpeg-8a stabilization request) Closing this one as fixed by jpeg-8a.
