Bug 560014 – crash while trying to view an image

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 560014 - crash while trying to view an image


Summary:	crash while trying to view an image


Status:	RESOLVED FIXED

Product:	gthumb
Classification:	Other
Component:	general
Version:	2.10.x
Hardware:	Other All

Importance:	Normal critical
Target Milestone:	---
Assigned To:	Paolo Bacchilega
QA Contact:	Paolo Bacchilega

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2008-11-09 13:56 UTC by Albert
Modified:	2009-09-23 12:50 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Albert 2008-11-09 13:56:45 UTC

Steps to reproduce:
from directory view, double-click the image.
the window disappears without a trace.


Stack trace:
(gdb) bt

+ Trace 209518

#0 ??
from /usr/lib/gthumb/libgthumb.so
#1 ??
from /usr/lib/gthumb/libgthumb.so
#2 get_metadata_time
from /usr/lib/gthumb/libgthumb.so
#3 ??
#4 ??
#5 ??
#6 g_cclosure_marshal_VOID__VOID
from /lib/libgobject-2.0.so.0
#7 g_closure_invoke
from /lib/libgobject-2.0.so.0
#8 ??
from /lib/libgobject-2.0.so.0
#9 g_signal_emit_valist
from /lib/libgobject-2.0.so.0
#10 g_signal_emit
from /lib/libgobject-2.0.so.0
#11 ??
from /usr/lib/gthumb/libgthumb.so
#12 g_cclosure_marshal_VOID__VOID
from /lib/libgobject-2.0.so.0
#13 g_closure_invoke
from /lib/libgobject-2.0.so.0
#14 ??
from /lib/libgobject-2.0.so.0
#15 g_signal_emit_valist
from /lib/libgobject-2.0.so.0
#16 g_signal_emit
from /lib/libgobject-2.0.so.0
#17 image_loader_load_from_image_loader
from /usr/lib/gthumb/libgthumb.so
#18 load_from_image_loader__step2
from /usr/lib/gthumb/libgthumb.so
#19 ??
from /usr/lib/gthumb/libgthumb.so
#20 ??
from /lib/libglib-2.0.so.0
#21 g_main_context_dispatch
from /lib/libglib-2.0.so.0
#22 ??
from /lib/libglib-2.0.so.0
#23 g_main_loop_run
from /lib/libglib-2.0.so.0
#24 gtk_main
from /usr/lib/libgtk-x11-2.0.so.0
#25 main



Other information:
Linux, Fedora 9, KDE 4.1

Comment 1 Michael Chudobiak 2008-11-09 18:50:54 UTC

What version of gthumb were you using?

- Mike

Comment 2 Albert 2008-11-11 19:18:39 UTC

Using version 2.10.8

I have build a gthumb from 2.10.8 source, and did the same experiment.

Core was generated by `/home/hat/Downloads/gthumb-2.10.8/src/.libs/lt-gthumb'.
Program terminated with signal 11, Segmentation fault.
[New process 29087]
[New process 29109]
[New process 29108]
[New process 29107]
[New process 29106]
[New process 29105]

+ Trace 209660

#0 de_get16
at gth-exif-utils.c line 360
#0 de_get16
at gth-exif-utils.c line 360
#1 gth_minimal_exif_tag_action
at gth-exif-utils.c line 479
#2 get_metadata_time
at gth-exif-utils.c line 198
#3 window_update_statusbar_image_info
at gth-browser.c line 482
#4 window_update_image_info
at gth-browser.c line 602
#5 image_loaded_cb
at gth-browser.c line 2756
#6 g_cclosure_marshal_VOID__VOID
from /lib/libgobject-2.0.so.0
#7 g_closure_invoke
from /lib/libgobject-2.0.so.0
#8 ??
from /lib/libgobject-2.0.so.0
#9 g_signal_emit_valist
from /lib/libgobject-2.0.so.0
#10 g_signal_emit
from /lib/libgobject-2.0.so.0
#11 image_loaded
at image-viewer.c line 2229
#12 g_cclosure_marshal_VOID__VOID
from /lib/libgobject-2.0.so.0


The call stack is as before, except with a few more details at the top.
(assuming the bottom part doesn't tell you much, I left it out this time)

As verification of ptr pointing to the wrong address:

(gdb) p *((char *)ptr)
Cannot access memory at address 0x76070556

Comment 3 Michael Chudobiak 2008-11-11 19:24:19 UTC

Can you try 2.10.10 instead? It is available here:

http://ftp.gnome.org/pub/GNOME/sources/gthumb/2.10/

This is probably a duplicate of bug 486886, which should be fixed in 2.10.10.

- Mike

Comment 4 Albert 2008-11-11 19:41:53 UTC

2.10.10 crashes too

Core was generated by `/home/hat/Downloads/gthumb-2.10.10/src/.libs/lt-gthumb'.
Program terminated with signal 11, Segmentation fault.
[New process 15530]
[New process 15557]
[New process 15556]
[New process 15555]
[New process 15554]
[New process 15553]

+ Trace 209661

#0 de_get16
at gth-exif-utils.c line 360
#0 de_get16
at gth-exif-utils.c line 360
#1 gth_minimal_exif_tag_action
at gth-exif-utils.c line 479
#2 get_metadata_time
at gth-exif-utils.c line 198
#3 window_update_statusbar_image_info
at gth-browser.c line 483
#4 window_update_image_info
at gth-browser.c line 603
#5 image_loaded_cb
at gth-browser.c line 2759
#6 g_cclosure_marshal_VOID__VOID
from /lib/libgobject-2.0.so.0

Comment 5 Albert 2008-11-11 19:49:43 UTC

Just before line 479 of gth-exif-utils.c, I added

printf("i=%d\n", i);

which gives as output:

i=-1235372154

(i'd say slightly out of bounds :) )

Comment 6 Michael Chudobiak 2008-11-11 20:27:49 UTC

Can you email the crash-causing image to mjc@avtechpulse.com?

Also, this code has been removed from the trunk version. If you feel adventurous, try compiling trunk.

- Mike

Comment 7 Michael Chudobiak 2008-11-11 20:54:56 UTC

OK, I understand if you can't provide a sample image. However, try using exiftool or other exif programs to see if there is anything "funny" or odd about the exif structure.

To try trunk, you would do something like this:

svn co http://svn.gnome.org/svn/gthumb/trunk gthumb-trunk
cd gthumb-trunk
./autogen.sh --prefix=/usr CFLAGS="-Wall -ggdb"
make
su
make install

You may need to install some development libraries (gnome-common, glib-devel, stuff like that).

- Mike

Comment 8 Albert 2008-11-12 19:44:32 UTC

With your instructions and a several additional packages, I managed to build a trunk version of gthumb (rev 2444).
I didn't install it, but ran the binary (cd src ; ./gthumb) after building (as I did with the 2.10.8 and 2.10.10 versions too).

This version seems to run fine. I can display the image just like any other image.

w.r.t. exif data, 'exiv2' reports there is not exif data, and 'jhead' only reports name, date, size, and resolution, even with a '-exifmap', which is supposed to do "Dump header bytes, annotate".



Thanks for a great program!!