Description of problem: First of all, ignore the core dump file because it is made artificially by sending kill -SIGSEGV to eom. I'm sorry, but I did this to launch bug report master with the right assign and product fields. The problem is this - eom (mate-image-viewer) not open the large svg file, whereas gwenview, for example - opens. Version-Release number of selected component: mate-image-viewer-1.5.0-2.fc18 Additional info: backtrace_rating: 4 cmdline: eom handlers.svg core_backtrace: executable: /usr/bin/eom kernel: 3.8.4-202.fc18.x86_64 uid: 1000 var_log_messages: Mar 25 12:26:56 localhost abrt[3696]: Saved core dump of pid 3586 (/usr/bin/eom) to /var/spool/abrt/ccpp-2013-03-25-12:26:55-3586 (63848448 bytes)
Created attachment 715904 [details] File: backtrace
Created attachment 715905 [details] File: cgroup
Created attachment 715906 [details] File: dso_list
Created attachment 715907 [details] File: environ
Created attachment 715908 [details] File: limits
Created attachment 715909 [details] File: maps
Created attachment 715910 [details] File: open_fds
Created attachment 715911 [details] File: proc_pid_status
Created attachment 715923 [details] svg file which eom can't show on this file eom shows error: Could not load image 'handlers.svg'. Error displaying image
Does this error ocours with latest updates and frequently?
Yes, this error occures with latest updates every time when I open svg file, which attached in my previous message. But for example firefox on this file work well at the same time.
If i try to open your svg with eom it fails to open but eom doesn't crash or triggered a abrt alarm. Same with using eog. Only with lnkscape it displayed well. But other svg files i can open without any problem with eom. Maybe it's a problem with the file itself? Can you open other svg files, ie. from a theme folder, with eom?
Also comix didn't display you svg file.
>If i try to open your svg with eom it fails to open but eom doesn't crash or >triggered a abrt alarm. See the description of problem: >First of all, ignore the core dump file because it is made artificially by >sending kill -SIGSEGV to eom. >I'm sorry, but I did this to launch bug report master with the right assign and >product fields. > >The problem is this - eom (mate-image-viewer) not open the large svg file, >whereas gwenview, for example - opens. I'm sorry, I'm newbie in sending bugreports and at that moment I didn't know how to choose right component to report to, so I artificially SIGSEGV eom to allow gnome-abrt do it for me. >Maybe it's a problem with the file itself? I believe this is good svg file, but might be it is too big. It's autogenerated graph of internal staff in one project using dot -Tsvg, and other such files opens without errors, until the graph size and, i.e. size of resulting svg file raise to certain value. And this example file also can be opened with several programs - inkscape, as you already know, gwenview, firefox, chromium-browser, and, with some issue in rendering - opera and midori. So I think this is bug of eom/eog. >Can you open other svg files, ie. from a theme folder, with eom? Yes, I can, other files work good.
(In reply to glad08 from comment #14) > >If i try to open your svg with eom it fails to open but eom doesn't crash or >triggered a abrt alarm. > > See the description of problem: > >First of all, ignore the core dump file because it is made artificially by >sending kill -SIGSEGV to eom. > >I'm sorry, but I did this to launch bug report master with the right assign and >product fields. > > > >The problem is this - eom (mate-image-viewer) not open the large svg file, >whereas gwenview, for example - opens. > > I'm sorry, I'm newbie in sending bugreports and at that moment I didn't know > how to choose right component to report to, so I artificially SIGSEGV eom to > allow gnome-abrt do it for me. Oh, sorry i didn't read this info. > >If i try to open your svg with eom it fails to open but eom doesn't crash or >triggered a abrt alarm. > > See the description of problem: > >First of all, ignore the core dump file because it is made artificially by >sending kill -SIGSEGV to eom. > >I'm sorry, but I did this to launch bug report master with the right assign and >product fields. > > > >The problem is this - eom (mate-image-viewer) not open the large svg file, >whereas gwenview, for example - opens. > > I'm sorry, I'm newbie in sending bugreports and at that moment I didn't know > how to choose right component to report to, so I artificially SIGSEGV eom to > allow gnome-abrt do it for me. > > >Maybe it's a problem with the file itself? > I believe this is good svg file, but might be it is too big. It's > autogenerated graph of internal staff in one project using dot -Tsvg, and > other such files opens without errors, until the graph size and, i.e. size > of resulting svg file raise to certain value. > And this example file also can be opened with several programs - inkscape, > as you already know, gwenview, firefox, chromium-browser, and, with some > issue in rendering - opera and midori. > > So I think this is bug of eom/eog. > > >Can you open other svg files, ie. from a theme folder, with eom? > Yes, I can, other files work good. Ok, i open a report at upstream for this https://github.com/mate-desktop/mate-image-viewer/issues/19
Thank you!
mate-image-viewer-1.6.1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mate-image-viewer-1.6.1-1.fc18
Package mate-image-viewer-1.6.1-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mate-image-viewer-1.6.1-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13837/mate-image-viewer-1.6.1-1.fc18 then log in and leave karma (feedback).
mate-image-viewer-1.6.1-1.fc18.x86_64 still can't show big svg files with many elements like attached example.
mate-image-viewer-1.6.1-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.