Package: libgdk-pixbuf2
Version: 0.22.0-11
Severity: important

Running a program that uses gdkpixbuf (in this case, freeciv 2.1) under
valgrind reveals numerous memory errors.  These all happen inside 
_gdk_pixbuf_load_module.  For instance:

==30756== Invalid read of size 4
==30756==    at 0x4010FB9: (within /lib/ld-2.3.5.so)
==30756==    by 0x400AFA9: (within /lib/ld-2.3.5.so)
==30756==    by 0x4007DBD: (within /lib/ld-2.3.5.so)
==30756==    by 0x490DEA8: do_sym (dl-sym.c:113)
==30756==    by 0x490E0EB: _dl_sym (dl-sym.c:154)
==30756==    by 0x45F2E60: dlsym_doit (dlsym.c:51)
==30756==    by 0x400B056: (within /lib/ld-2.3.5.so)
==30756==    by 0x45F32FF: _dlerror_run (dlerror.c:162)
==30756==    by 0x45F2EC0: dlsym (dlsym.c:71)
==30756==    by 0x45F039E: g_module_symbol (in 
/usr/lib/libgmodule-2.0.so.0.800.5)
==30756==    by 0x45F08CF: g_module_open (in 
/usr/lib/libgmodule-2.0.so.0.800.5)==30756==    by 0x43E8593: 
_gdk_pixbuf_load_module (gdk-pixbuf-io.c:456)
==30756==    by 0x43E8E61: gdk_pixbuf_new_from_file (gdk-pixbuf-io.c:883)
==30756==    by 0x81473C4: load_gfxfile (sprite.c:197)
==30756==    by 0x808754E: load_gfx_file (tilespec.c:1011)
==30756==    by 0x8087680: ensure_big_sprite (tilespec.c:1050)
==30756==    by 0x8089901: load_sprite (tilespec.c:1698)
==30756==    by 0x808A25D: tileset_lookup_sprite_tags (tilespec.c:1979)
==30756==    by 0x808D881: tileset_load_tiles (tilespec.c:2468)
==30756==    by 0x812A4A1: ui_main (gui_main.c:1314)
==30756==    by 0x8059C33: main (civclient.c:378)
==30756==  Address 0x53B6E94 is 52 bytes inside a block of size 54 alloc'd
==30756==    at 0x401B41A: malloc (vg_replace_malloc.c:149)
==30756==    by 0x4003D27: (within /lib/ld-2.3.5.so)
==30756==    by 0x40064DA: (within /lib/ld-2.3.5.so)
==30756==    by 0x490BE70: dl_open_worker (dl-open.c:259)
==30756==    by 0x400B056: (within /lib/ld-2.3.5.so)
==30756==    by 0x490C754: _dl_open (dl-open.c:577)
==30756==    by 0x45F2D2E: dlopen_doit (dlopen.c:59)
==30756==    by 0x400B056: (within /lib/ld-2.3.5.so)
==30756==    by 0x45F32FF: _dlerror_run (dlerror.c:162)
==30756==    by 0x45F2D9C: dlopen@@GLIBC_2.1 (dlopen.c:78)
==30756==    by 0x45F05C0: g_module_open (in 
/usr/lib/libgmodule-2.0.so.0.800.5)==30756==    by 0x43E8593: 
_gdk_pixbuf_load_module (gdk-pixbuf-io.c:456)
==30756==    by 0x43E8E61: gdk_pixbuf_new_from_file (gdk-pixbuf-io.c:883)
==30756==    by 0x81473C4: load_gfxfile (sprite.c:197)
==30756==    by 0x808754E: load_gfx_file (tilespec.c:1011)
==30756==    by 0x8087680: ensure_big_sprite (tilespec.c:1050)
==30756==    by 0x8089901: load_sprite (tilespec.c:1698)
==30756==    by 0x808A25D: tileset_lookup_sprite_tags (tilespec.c:1979)
==30756==    by 0x808D881: tileset_load_tiles (tilespec.c:2468)
==30756==    by 0x812A4A1: ui_main (gui_main.c:1314)
==30756==    by 0x8059C33: main (civclient.c:378)

In this case the malloc simply isn't big enough, or perhaps the read is in
the wrong place.  This is a bizarre and fairly serious error, I suspect.

I don't really know that this error is caused by gdkpixbuf; it could be
directly within the dl code.  However the dl functions do not have symbol
information it seems, and I don't know why (I have libc6-dbg installed).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages libgdk-pixbuf2 depends on:
ii  libc6                         2.3.5-11   GNU C Library: Shared libraries an
ii  libgtk1.2                     1.2.10-18  The GIMP Toolkit set of widgets fo
ii  libjpeg62                     6b-11      The Independent JPEG Group's JPEG 
ii  libpng12-0                    1.2.8rel-5 PNG library - runtime
ii  libtiff4                      3.7.4-1    Tag Image File Format (TIFF) libra

libgdk-pixbuf2 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to