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 85448 - crash in loading bmp
crash in loading bmp
Status: RESOLVED FIXED
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other other
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-06-16 09:36 UTC by Markus Bertheau
Modified: 2010-07-10 04:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.0

Attachments
the file mentioned in the backtrace (12.56 KB, image/bmp)
2002-06-16 10:04 UTC, Markus Bertheau 		  Details
patch (5.63 KB, patch)
2002-06-22 15:04 UTC, Matthias Clasen 		none Details | Review

Description Markus Bertheau 2002-06-16 09:36:09 UTC 
Package: gtk+
Severity: major
Version: 2.0.0
Synopsis: crash in loading bmp
Bugzilla-Product: gtk+
Bugzilla-Component: gdk-pixbuf
BugBuddy-GnomeVersion: 2.0 (2.0.1)

Description:
Description of Problem:
This is nautilus browsing a windows c:\windows directory. I hope I read
the backtrace right in that that is a gdk bug. I'll attach the file in
question.





Debugging Information:

Backtrace was generated from '/gnome/head/INSTALL/bin/nautilus'

0x40bbca39 in wait4 () from /lib/libc.so.6

+ Trace 23891

  • #0 wait4
    from /lib/libc.so.6
  • #1 __check_rhosts_file
    from /lib/libc.so.6
  • #2 waitpid
    from /lib/libpthread.so.0
  • #3 libgnomeui_segv_handle
    at gnome-ui-init.c line 620
  • #4 pthread_kill
    from /lib/libpthread.so.0
  • #5 sigaction
    from /lib/libc.so.6
  • #6 g_log
    at gmessages.c line 526
  • #7 g_realloc
    at gmem.c line 174
  • #8 DecodeHeader
    at io-bmp.c line 404
  • #9 gdk_pixbuf__bmp_image_load_increment
    at io-bmp.c line 1000
  • #10 gdk_pixbuf__bmp_image_load
    at io-bmp.c line 218
  • #11 gdk_pixbuf_new_from_file
    at gdk-pixbuf-io.c line 626
  • #12 load_icon_from_path
    at nautilus-icon-factory.c line 1584
  • #13 load_specific_icon
    at nautilus-icon-factory.c line 1644
  • #14 get_icon_from_cache
    at nautilus-icon-factory.c line 2038
  • #15 load_icon_for_scaling
    at nautilus-icon-factory.c line 1720
  • #16 load_icon_scale_if_necessary
    at nautilus-icon-factory.c line 1873
  • #17 get_icon_from_cache
    at nautilus-icon-factory.c line 2061
  • #18 nautilus_icon_factory_get_pixbuf_for_icon
    at nautilus-icon-factory.c line 2113
  • #19 nautilus_icon_container_update_icon
    at nautilus-icon-container.c line 3826
  • #20 finish_adding_icon
    at nautilus-icon-container.c line 3942
  • #21 finish_adding_new_icons
    at nautilus-icon-container.c line 3969
  • #22 redo_layout_internal
    at nautilus-icon-container.c line 1236
  • #23 redo_layout_callback
    at nautilus-icon-container.c line 1261
  • #24 g_idle_dispatch
    at gmain.c line 3129
  • #25 g_main_dispatch
    at gmain.c line 1617
  • #26 g_main_context_dispatch
    at gmain.c line 2161
  • #27 g_main_context_iterate
    at gmain.c line 2242
  • #28 g_main_loop_run
    at gmain.c line 2462
  • #29 gtk_main
    at gtkmain.c line 936
  • #30 main
    at nautilus-main.c line 263
  • #31 __libc_start_main
    from /lib/libc.so.6 




------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-06-16 05:36 -------

Reassigning to the default owner of the component, gtk-bugs@gtk.org.
Comment 1 Markus Bertheau 2002-06-16 10:04:03 UTC 
Created attachment 9252 [details]
the file mentioned in the backtrace
Comment 2 Owen Taylor 2002-06-16 13:54:08 UTC 
Crash verified. Seems to be a combination of something going
wrong with header parsing and an unchecked g_realloc().
Comment 3 Matthias Clasen 2002-06-22 15:03:05 UTC 
The bmp in question is invalid, it contains a wrong offset field. 
bmptoppm correctly complains about this (and even tells the correct
value), but of course gdk-pixbuf shouldn't crash on any image. 
Interestingly, ImageMagick and xv manage to display the bmp correctly,
since they don't use the offset field in question. 

Here is a first patch which a) removes all unchecked reallocs from
io-bmp.c and b) makes gdk-pixbuf display the invalid bmp by 
not using the offset field in question, in the same way xv and 
ImageMagick do.

There are more problems in io-bmp.c though. valgrind reports some
memleaks and invalid reads.
Comment 4 Matthias Clasen 2002-06-22 15:04:03 UTC 
Created attachment 9400 [details] [review]
patch
Comment 5 Matthias Clasen 2002-06-22 22:56:16 UTC 
Turns out the only change I need in order to silence valgrind is to
change the Compressed field in the bmp_progressive_state struct from
gint to guint, so that negative values don't slip through the sanity
checks in DecodeHeader.
Comment 6 Matthias Clasen 2002-06-23 21:08:12 UTC 
The change to the offset calculation for displaying the broken bmp
breaks loading of certain valid bmps, thus the old code should probably
be left in place.
Comment 7 Matthias Clasen 2002-07-02 18:00:11 UTC 
Crash fix committed to both branches.
Comment 8 Matthias Clasen 2002-07-03 08:13:40 UTC 
Reopened for pixbuf-stable.
Comment 9 Federico Mena Quintero 2002-09-27 21:43:51 UTC 
Backported, marking as fixed.