libreport version: 2.0.7 abrt_version: 2.0.6 backtrace_rating: 4 cmdline: mupdf /media/REPOS/z-pre-rm1.pdf comment: Running mupdf on LaTeX-created PDF crash_function: __GI_raise executable: /usr/bin/mupdf kernel: 3.1.0-7.fc16.i686 pid: 4953 pwd: /home/vedranm reason: Process /usr/bin/mupdf was killed by signal 6 (SIGABRT) time: Wed 09 Nov 2011 12:30:05 PM CET uid: 1000 username: vedranm xsession_errors: backtrace: Text file, 12539 bytes environ: Text file, 2975 bytes maps: Text file, 3819 bytes smolt_data: Text file, 2650 bytes dso_list: :/lib/libdl-2.14.90.so glibc-2.14.90-14.i686 (Fedora Project) 1320287345 :/usr/lib/libfreetype.so.6.7.1 freetype-2.4.6-3.fc16.i686 (Fedora Project) 1320287348 :/lib/libgcc_s-4.6.2-20111027.so.1 libgcc-4.6.2-1.fc16.i686 (Fedora Project) 1320287340 :/usr/lib/libX11.so.6.3.0 libX11-1.4.3-1.fc16.i686 (Fedora Project) 1320287350 :/usr/lib/libXext.so.6.4.0 libXext-1.2.0-2.fc15.i686 (Fedora Project) 1320287350 :/usr/lib/libXcursor.so.1.0.2 libXcursor-1.1.11-3.fc15.i686 (Fedora Project) 1320287350 :/usr/bin/mupdf mupdf-0.9-1.fc16.i686 (Fedora Project) 1320838203 :/lib/ld-2.14.90.so glibc-2.14.90-14.i686 (Fedora Project) 1320287345 :/usr/lib/libxcb.so.1.1.0 libxcb-1.7-3.fc16.i686 (Fedora Project) 1320287350 :/lib/libm-2.14.90.so glibc-2.14.90-14.i686 (Fedora Project) 1320287345 :/usr/lib/libXrender.so.1.3.0 libXrender-0.9.6-2.fc15.i686 (Fedora Project) 1320287350 :/usr/lib/libXau.so.6.0.0 libXau-1.0.6-2.fc15.i686 (Fedora Project) 1320287350 :/usr/lib/libjbig2dec.so.0.0.0 jbig2dec-libs-0.11-3.fc15.i686 (Fedora Project) 1320838199 :/lib/libz.so.1.2.5 zlib-1.2.5-4.fc16.i686 (Fedora Project) 1320287348 :/usr/lib/libXfixes.so.3.1.0 libXfixes-5.0-1.fc16.i686 (Fedora Project) 1320287350 :/lib/libc-2.14.90.so glibc-2.14.90-14.i686 (Fedora Project) 1320287345 :/usr/lib/libjpeg.so.62.0.0 libjpeg-turbo-1.1.1-1.fc16.i686 (Fedora Project) 1320287348 :/usr/lib/libopenjpeg.so.3.1.4.0 openjpeg-libs-1.4-6.fc16.i686 (Fedora Project) 1320287357 event_log: :2011-11-09-12:30:28> Querying server settings :2011-11-09-12:30:30 Preparing an archive to upload :2011-11-09-12:30:31 Uploading 448032 bytes :2011-11-09-12:30:37 Upload successful :2011-11-09-12:30:37 Retrace job started :2011-11-09-12:30:48 Initializing virtual root :2011-11-09-12:30:59 Initializing virtual root :2011-11-09-12:31:10 Initializing virtual root :2011-11-09-12:31:21 Initializing virtual root :2011-11-09-12:31:32 Initializing virtual root :2011-11-09-12:31:43 Initializing virtual root :2011-11-09-12:31:56 Cleaning up virtual root :2011-11-09-12:32:09 Retrace job finished successfully :2011-11-09-12:35:06> Element 'xsession_errors' saved :2011-11-09-12:35:12> Smolt profile successfully saved var_log_messages: :Nov 9 12:30:03 calabria yum[4809]: Installed: mupdf-0.9-1.fc16.i686 :Nov 9 12:30:05 calabria abrt[4954]: Saved core dump of pid 4953 (/usr/bin/mupdf) to /var/spool/abrt/ccpp-2011-11-09-12:30:05-4953 (5210112 bytes)
Created attachment 532543 [details] File: environ
Created attachment 532544 [details] File: smolt_data
Created attachment 532545 [details] File: maps
Created attachment 532546 [details] File: backtrace
Opening PDF file and crashed. backtrace_rating: 4 Package: mupdf-0.9-1.fc16 OS Release: Fedora release 16 (Verne)
Created attachment 567316 [details] File: backtrace
Really? I have mupdf-0.9-1.fc16.x86_64 and tried a few latex-generated PDFs. From the two redhat bugzilla backtraces though, it looks like it is string buffer overrun. Does your LaTeX pdf's have extremely long titles? apps/pdfapps.c: line 360 -ish, have this: ----------- static void pdfapp_showpage(pdfapp_t *app, int loadpage, int drawpage, int repaint) { char buf[256]; ----------- could you try changing the 256 to some large number, and/or the sprintf() a few lines down, to snprintf(buf, 256, ...)? --------------- if (drawpage) { sprintf(buf, "%s - %d/%d (%d dpi)", app->doctitle, -------------
Created attachment 569157 [details] a pdf with a stupidously long pdfdoc title Based on my inspection of the mupdf code and my suspection that I can overrun that string buffer, I made a pdf with a stupideously long pdfdoc title. And it crashes mupdf. Both xpdf and gs are happy to open it.
I've tried to reproduce bug on F17. All latex generated files have been opened successfully. Vedran, can you attach pdf file?
(In reply to comment #9) > I've tried to reproduce bug on F17. All latex generated files have been opened > successfully. > Vedran, can you attach pdf file? The pdf attached in comment 8 was latex-generated - although it was specifically constructed to try to trigger the suspected (and confirmed) buffer overrun. The important part of the latex doc code which triggers the buffer overrun is the pdftitle parameter of hyperref - something like this: -------------------------------- \documentclass[11pt]{article} \usepackage[...other options..., pdftitle={A very long long string}]{hyperref} ... ------------------------------- It looks like there are a few other buffer overrun possibility in the same mupdf source file, however.
mupdf-0.9-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mupdf-0.9-3.fc16
Package mupdf-0.9-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mupdf-0.9-3.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4122/mupdf-0.9-3.fc16 then log in and leave karma (feedback).
mupdf-0.9-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.