After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 780573 - random crash (SIGABRT)
random crash (SIGABRT)
Product: eog
Classification: Core
Component: general
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Reported: 2017-03-27 03:25 UTC by Paul Wise
Modified: 2021-06-19 08:47 UTC
See Also:
GNOME target: ---
GNOME version: 3.21/3.22

gdb backtrace of the crash (16.00 KB, text/plain)
2017-03-27 03:25 UTC, Paul Wise

Description Paul Wise 2017-03-27 03:25:33 UTC
Created attachment 348765 [details]
gdb backtrace of the crash

I am using eog 3.20.5-1+b1 with GNOME 3.22 on Debian stretch. I don't know exactly how I managed to crash eog and I can't reproduce it right now but it was while I was viewing this screenshot from dropbox. If the below backtrace summary and the attached full backtrace aren't useful, please close this bug.

Core was generated by `eog /tmp/user/1000/Screen Shot 2017-03-08 at 08.20.36.png'.
Program terminated with signal SIGABRT, Aborted.
  • #0 __GI_raise
    at ../sysdeps/unix/sysv/linux/raise.c line 58
  • #0 __GI_raise
    at ../sysdeps/unix/sysv/linux/raise.c line 58
  • #1 __GI_abort
    at abort.c line 89
  • #2 g_assertion_message
  • #3 g_assertion_message_expr
    at ././glib/gtestutils.c line 2455
  • #4 eog_image_real_load
    at eog-image.c line 921
  • #5 eog_image_load
  • #6 eog_job_load_run
    at eog-jobs.c line 573
  • #7 eog_job_process
    at eog-job-scheduler.c line 153
  • #8 eog_job_scheduler
    at eog-job-scheduler.c line 128
  • #9 g_thread_proxy
    at ././glib/gthread.c line 784
  • #10 start_thread
    at pthread_create.c line 333
  • #11 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 105

Comment 1 Felix Riemann 2017-04-19 16:12:40 UTC
I can't reproduce it either, at least from the image file alone. The weird part is the assertion it trips over indicated that the image has loaded already once.
Maybe it's a problem which is triggered by how the Dropbox client syncs the file.

Was it the only image in that folder?

Do you have any plugins activated which might trigger image loading, e.g. for metadata?
Comment 2 Paul Wise 2017-04-20 07:03:22 UTC
The Drobox client wasn't involved, I downloaded it using my browser.

I didn't keep a record of other files in that folder, so there could have been some more images or not.

The only plugin I have enabled is "Fullscreen with double-click".
Comment 3 André Klapper 2021-06-19 08:47:46 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.