abrt 1.0.8 detected a crash. architecture: i686 Attached file: backtrace cmdline: evince LDDE_Training-2.3_2010.pdf component: evince executable: /usr/bin/evince kernel: 2.6.32.9-70.fc12.i686 package: evince-2.28.2-1.fc12 rating: 4 reason: Process /usr/bin/evince was killed by signal 8 (SIGFPE) release: Fedora release 12 (Constantine) comment ----- Here the "core" file generated during my session (45Mb) http://jau.free.fr/core.3669 I tried to debug evince (with debuginfo) and I cannot really say where is the issue: pixman or cairo ? the error is raise in pixman (probably a % by 0) *coord = MOD (*coord, size); - see thread 1 / #0 entry (pixman-bits-image.c) but maybe cairo ask something wrong to pixman... I've try to upgrade to the latest pixman-0.17.10-1 & cairo-1.8.10-1 (from koji & rebuild for F12) but it doesn't improve (same error at same place) I also try to open this PDF from F13alpha using evince, and same crash at same place. I have no problem to use this PDF using evince on CentOS-5.4 ! The only workarround I have now is to upgrade to cairo-1.9.6 (on F12) => no crash, no error... And I don't see (yet) any bad artefact due to cairo-1.9.6 usage on the desktop. The PDF was generated using OOo 2.3 / Impress (PDF v1.4) How to reproduce ----- 1. Open a specific PDF (sorry, I cannot share this one...) using evince 2. scroll up/down from page 14 to page 13 3. crash evince: Floating point exception (core dumped)
Created attachment 399441 [details] File: backtrace
Error seem due to (bad ?) usage of SSE in pixmap implementation. I've also use "valgrind evince ./LDDE_Training-2.3_2010.pdf" to check error, but, he never crash !! => that's why I think that an SSE issue (I'm not sure but I don't think valgrind emulate SSE)
Seems similar to https://bugs.freedesktop.org/show_bug.cgi?id=24693
(In reply to comment #3) > Seems similar to > > https://bugs.freedesktop.org/show_bug.cgi?id=24693 Thanks for the link. It's clearly the same problem I have. Finally, I added one check into "cairo" to avoid the calling pixmap when src->width & src->height is NULL It fix my issue with my PDF (and also for the PDF in freedesktop bugzilla)
Created attachment 401271 [details] This patch add some check for NULL size of cairo_image_surface_t *src
(In reply to comment #5) > Created an attachment (id=401271) [details] > This patch add some check for NULL size of cairo_image_surface_t *src Then clean way is probably to check this in _cairo_surface_clone_similar(..., cairo_surface_t **clone_out) - cairo-surface.c !(*clone_out->width) && !(*clone_out->heigth) But, I think it's better to ask to "cairo" developer to avoid breaking something.
Hi Audu, I'm confirming that the cairo upstream patch from the bug #24693 fixes this crash. I'm reassigning this to cairo. Thank you for your informations Marek
*** Bug 557388 has been marked as a duplicate of this bug. ***
*** Bug 591621 has been marked as a duplicate of this bug. ***
*** Bug 591623 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
cairo-1.10.0-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/cairo-1.10.0-1.fc14
cairo-1.10.0-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cairo'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/cairo-1.10.0-1.fc14
*** Bug 629146 has been marked as a duplicate of this bug. ***
cairo-1.10.0-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.