pdftocairo (part of poppler) gives Bus Error: 10

[gdasnon@…]

Hi,

I sent this bug to poppler support (​https://bugs.freedesktop.org/show_bug.cgi?id=74661) which indicates that it's working very well in their environment, so maybe this problem only occurs in Macports.

pdftocairo command works well except in some cases.

I use this command :

/opt/local/bin/pdftocairo -r 150 -jpeg /Users/myname/Desktop/Languedoc_001A047_XP8_FP_p17.pdf /Users/myname/Desktop/Languedoc_001A047_XP8_FP_p17

And it gives this error :

Bus error: 10

Here's my environment :
Mac OS X 10.9.1
XCode 5.0.2 with command line tools
MacPorts 2.2.1
poppler 0.24.5 installed
Many other ports installed like ImageMagick (unknown on your ports search tool) and Xpdf.
All ports are up to date.

I send 3 files : the crash report, the dtruss output and the PDF file.

Thanks for your help.
Best regards.

Guillaume

[ryandesign (Ryan Carsten Schmidt)]

Replying to gdasnon@…:

Many other ports installed like ImageMagick (unknown on your ports search tool) and Xpdf.

Because of #40946.

[cooljeanius (Eric Gallager)]

Cc Me!

[dbevans (David B. Evans)]

I can reproduce the error you describe on 10.8 as well so probably not a Mavericks specific issue. So far, I can only reproduce it using the file that you provided and the error occurs when trying to convert it to any pixel based format (png, jpeg, tiff). Converting to ps, pdf or svg works OK.

Interestingly, using pdftocairo to first (re-)convert to an intermediate pdf file and then convert that file to jpeg works fine.

pdftocairo -pdf Languedoc_001A047_XP8_FP_p17.pdf test.pdf
pdftocairo -jpeg test.pdf test.jpg

creates a good jpeg of the original. So perhaps this can be used as a work around.

I note that according to pdfinfo the original file is in PDF 1.3, optimized format, while the regenerated pdf file is in PDF 1.5, not optimized.

Running the command in gdb produces the following error and backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000001006f94d0
0x00000001005e63d5 in _cairo_clip_intersect_rectangle_box (clip=0x1006f94a0, r=0x7fff5fbfe2e8, box=0x7fff5fbfe34c) at cairo-clip-boxes.c:179
179		    clip->is_region = _cairo_box_is_pixel_aligned (box);
(gdb) bt
#0  0x00000001005e63d5 in _cairo_clip_intersect_rectangle_box (clip=0x1006f94a0, r=0x7fff5fbfe2e8, box=0x7fff5fbfe34c) at cairo-clip-boxes.c:179
#1  0x00000001005e62ad in _cairo_clip_intersect_box (clip=0x10102f8d0, box=0x7fff5fbfe34c) at cairo-clip-boxes.c:265
#2  0x000000010065291c in _cairo_spans_compositor_stroke (_compositor=0x1007292d8, extents=0x7fff5fbfe9d8, path=0x101814d68, style=0x7fff5fbfeeb0, ctm=0x1010476c0, ctm_inverse=0x1010476f0, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT) at cairo-spans-compositor.c:1070
#3  0x00000001005e990f in _cairo_compositor_stroke (compositor=0x1007292d8, surface=0x101023b00, op=CAIRO_OPERATOR_OVER, source=0x7fff5fbfeee0, path=0x101814d68, style=0x7fff5fbfeeb0, ctm=0x1010476c0, ctm_inverse=0x1010476f0, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x10102c390) at cairo-compositor.c:157
#4  0x0000000100606660 in _cairo_image_surface_stroke (abstract_surface=0x101023b00, op=CAIRO_OPERATOR_OVER, source=0x7fff5fbfeee0, path=0x101814d68, style=0x7fff5fbfeeb0, ctm=0x1010476c0, ctm_inverse=0x1010476f0, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x10102c390) at cairo-image-surface.c:961
#5  0x000000010065bcd1 in _cairo_surface_stroke (surface=0x101023b00, op=CAIRO_OPERATOR_OVER, source=0x7fff5fbfeee0, path=0x101814d68, stroke_style=0x7fff5fbfeeb0, ctm=0x1010476c0, ctm_inverse=0x1010476f0, tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT, clip=0x10102c390) at cairo-surface.c:2210
#6  0x00000001005f5165 in _cairo_gstate_stroke (gstate=0x1010475d0, path=0x101814d68) at cairo-gstate.c:1185
#7  0x00000001005edeae in _cairo_default_context_stroke (abstract_cr=0x101814a00) at cairo-default-context.c:1013
#8  0x00000001005e0f0a in cairo_stroke (cr=0x101814a00) at cairo.c:2146
#9  0x000000010000db84 in CairoOutputDev::stroke (this=0x101021240, state=0x101048000) at CairoOutputDev.cc:776
#10 0x00000001000a2fae in Gfx::opStroke (this=0x101023c80, args=0x7fff5fbff290, numArgs=0) at Gfx.cc:1801
#11 0x00000001000aa100 in Gfx::execOp (this=0x101023c80, cmd=0x7fff5fbff4a8, args=0x7fff5fbff290, numArgs=0) at Gfx.cc:853
#12 0x00000001000a993c in Gfx::go (this=0x101023c80, topLevel=true) at Gfx.cc:712
#13 0x00000001000a96cc in Gfx::display (this=0x101023c80, obj=0x7fff5fbff638, topLevel=true) at Gfx.cc:678
#14 0x000000010010cf29 in Page::displaySlice (this=0x101023600, out=0x101021240, 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:584
#15 0x0000000100111dd2 in PDFDoc::displayPageSlice (this=0x101020610, out=0x101021240, 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:493
#16 0x00000001000079a8 in renderPage (doc=0x101020610, cairoOut=0x101021240, pg=1, page_w=1105.51, page_h=765.35399999999993, output_w=2304, output_h=1595) at pdftocairo.cc:581
#17 0x00000001000068d3 in main (argc=3, argv=0x7fff5fbffae0) at pdftocairo.cc:1046

Setting a breakpoint at CairoOutputDev::stroke shows that it hits this breakpoint many, many times before the final error but I haven't been able to track it down to the specific element in the pdf file that triggers it.

My guess based on all of this is that the problem is the result of some combination of a specific element instance in the original file format and way poppler parses that when creating (via cairo) a pixel based output format and that this occurs very rarely. I don't see any indication so far that it has anything to do with MacPorts per se.

Hopefully the work around that I described above will help you get done what you need to do. Do you have other pdf files where this occurs?

[dbevans (David B. Evans)]

(Replying to email response -- Please reply to the ticket here.)

Hi,
thank you very much for your feedback and the workaround, i'll use it to solve my needs.

I have one question : what's the next step ?
As i wrote in this ticket, i also sent this bug to poppler support : this problem has to be solved by poppler team or by Macports team ?

Let me know if i can help in any way.

Thanks again for your help.

Best regards.

Guillaume

As suggested in the poppler bug report that you filed, further debugging is required to understand the precise failure mode before it can be understood how to fix it and who should do it.

From the preliminary debugging cited above, it appears that either Poppler is sending bad information to cairo_stroke() or cairo_stroke() itself is failing on legitimate input.

Next step is to examine the cairo context passed to cairo_stoke() at the time of the error and see how that is causing the memory access error. Once this is understood the results can be forwarded to the appropriate developers for action.

If you or anyone else can demonstrate the problem with a simpler pdf file, please let me know as that would help a lot.

Glad that you are able to make progress at any rate. I'll leave this ticket open for now to remind that the issue exists and will try to look at it further when time permits.

[dbevans (David B. Evans)]

Pointer to this ticket added to poppler ticket ​https://bugs.freedesktop.org/show_bug.cgi?id=74661.

[mmitar@…]

Cc Me!

[mmitar@…]

OK. This is interesting. I found this ticket searching for more information for same segfault but on a completely different stack. I am maintainer of a ​meteor-pdf.js package which provides support for running ​PDF.js on the server inside node.js. PDF.js uses HTML5 to render PDFs and I use ​node-canvas on the server to simulate HTML5 canvas element. node-canvas uses Cairo to render. And what is interesting is that I get same stack trace and segfault on one PDF (on many others it works correctly).

​This is PDF which is giving me trouble. Can somebody test it with pdftocairo?

[mmitar@…]

I have Mac OS X 10.7.5.

[mmitar@…]

Running it with linked to current master from Cairo git repository solved the issue for me. It segfaults with 1.12.16, but it works with master (4144307dbfbe7b297135d9ea4b080cae7e06b997).

[mmitar@…]

Update: it seems it works with 1.12.16 from repository as well. It fails with Cairo installed from Homebrew or one installed with XQuartz.

[chrstphrchvz (Christopher Chavez)]

Replying to dbevans:

Pointer to this ticket added to poppler ticket ​https://bugs.freedesktop.org/show_bug.cgi?id=74661.

The upstream ticket has since been closed as fixed. Should this ticket be closed?

[kencu (Ken)]

fixed as of 2014. please reopen a new ticket if you find this is still an issue.