Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159701 - Invalid read reported by valgrind
Summary: Invalid read reported by valgrind
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-07 08:54 UTC by Kjartan Maraas
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-06 21:45:44 UTC


Attachments (Terms of Use)

Description Kjartan Maraas 2005-06-07 08:54:45 UTC
Description of problem:

I get this from valgrind when running the gnome-panel:

==670== Invalid read of size 4
==670==    at 0x1B8F9BB3: index (in /lib/ld-2.3.5.so)
==670==    by 0x1B8EB74A: expand_dynamic_string_token (in /lib/ld-2.3.5.so)
==670==    by 0x1B8EC2B0: _dl_map_object (in /lib/ld-2.3.5.so)
==670==    by 0x1B8F4FF3: dl_open_worker (in /lib/ld-2.3.5.so)
==670==    by 0x1B8F1A0F: _dl_catch_error (in /lib/ld-2.3.5.so)
==670==    by 0x1B8F5741: _dl_open (in /lib/ld-2.3.5.so)
==670==    by 0x1C60AD41: dlopen_doit (in /lib/libdl-2.3.5.so)
==670==    by 0x1B8F1A0F: _dl_catch_error (in /lib/ld-2.3.5.so)
==670==    by 0x1C60B3F9: _dlerror_run (in /lib/libdl-2.3.5.so)
==670==    by 0x1C60ADD1: dlopen@@GLIBC_2.1 (in /lib/libdl-2.3.5.so)
==670==    by 0x1C608442: g_module_open (gmodule-dl.c:98)
==670==    by 0x1C23AF4B: gtk_theme_engine_load (gtkthemes.c:80)
==670==    by 0x1C5D43B0: g_type_module_use (gtypemodule.c:190)
==670==    by 0x1C23B14E: gtk_theme_engine_get (gtkthemes.c:181)
==670==    by 0x1C1E6500: gtk_rc_parse_style (gtkrc.c:3186)
==670==    by 0x1C1E6957: gtk_rc_parse_any (gtkrc.c:2426)
==670==    by 0x1C1E6F1B: gtk_rc_context_parse_one_file (gtkrc.c:828)
==670==    by 0x1C1E6FF9: gtk_rc_context_parse_file (gtkrc.c:894)
==670==    by 0x1C1E71F5: gtk_rc_parse_named (gtkrc.c:645)
==670==    by 0x1C1E75AF: gtk_rc_reparse_all_for_settings (gtkrc.c:1526)
==670==    by 0x1C1F2F73: gtk_settings_get_for_screen (gtksettings.c:490)
==670==    by 0x1C1F2FFE: gtk_settings_get_default (gtksettings.c:512)
==670==    by 0x1C1F9CD1: gtk_style_init (gtkstyle.c:549)
==670==    by 0x1C5D3673: g_type_create_instance (gtype.c:1596)
==670==    by 0x1C5BA77B: g_object_constructor (gobject.c:1045)
==670==    by 0x1C5BADD7: g_object_newv (gobject.c:942)
==670==    by 0x1C5BB8E8: g_object_new_valist (gobject.c:985)
==670==    by 0x1C5BBA5D: g_object_new (gobject.c:823)
==670==    by 0x1C1FA378: gtk_style_new (gtkstyle.c:821)
==670==    by 0x1C2811D4: gtk_widget_get_default_style (gtkwidget.c:5006)
==670==  Address 0x1CC76DA0 is 48 bytes inside a block of size 51 alloc'd
==670==    at 0x1B9043DA: malloc (vg_replace_malloc.c:220)
==670==    by 0x1C6685C1: g_malloc (gmem.c:137)
==670==    by 0x1C6788E9: g_strdup (gstrfuncs.c:91)
==670==    by 0x1C6084FF: g_module_open (gmodule.c:353)
==670==    by 0x1C23AF4B: gtk_theme_engine_load (gtkthemes.c:80)
==670==    by 0x1C5D43B0: g_type_module_use (gtypemodule.c:190)
==670==    by 0x1C23B14E: gtk_theme_engine_get (gtkthemes.c:181)
==670==    by 0x1C1E6500: gtk_rc_parse_style (gtkrc.c:3186)
==670==    by 0x1C1E6957: gtk_rc_parse_any (gtkrc.c:2426)
==670==    by 0x1C1E6F1B: gtk_rc_context_parse_one_file (gtkrc.c:828)
==670==    by 0x1C1E6FF9: gtk_rc_context_parse_file (gtkrc.c:894)
==670==    by 0x1C1E71F5: gtk_rc_parse_named (gtkrc.c:645)
==670==    by 0x1C1E75AF: gtk_rc_reparse_all_for_settings (gtkrc.c:1526)
==670==    by 0x1C1F2F73: gtk_settings_get_for_screen (gtksettings.c:490)
==670==    by 0x1C1F2FFE: gtk_settings_get_default (gtksettings.c:512)
==670==    by 0x1C1F9CD1: gtk_style_init (gtkstyle.c:549)
==670==    by 0x1C5D3673: g_type_create_instance (gtype.c:1596)
==670==    by 0x1C5BA77B: g_object_constructor (gobject.c:1045)
==670==    by 0x1C5BADD7: g_object_newv (gobject.c:942)
==670==    by 0x1C5BB8E8: g_object_new_valist (gobject.c:985)
==670==    by 0x1C5BBA5D: g_object_new (gobject.c:823)
==670==    by 0x1C1FA378: gtk_style_new (gtkstyle.c:821)
==670==    by 0x1C2811D4: gtk_widget_get_default_style (gtkwidget.c:5006)
==670==    by 0x1C28126F: gtk_widget_init (gtkwidget.c:1672)
==670==    by 0x1C5D349A: g_type_create_instance (gtype.c:1588)
==670==    by 0x1C5BA77B: g_object_constructor (gobject.c:1045)
==670==    by 0x1C5BADD7: g_object_newv (gobject.c:942)
==670==    by 0x1C5BB93E: g_object_new_valist (gobject.c:1026)
==670==    by 0x1C5BBA5D: g_object_new (gobject.c:823)
==670==    by 0x8093042: panel_profile_load_toplevel (panel-profile.c:1585)

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jakub Jelinek 2005-06-13 16:11:43 UTC
Can you rerun it with --db-attach=yes and see what string it is?
I bet that is a false positive from valgrind, index (aka strchr) reads
(longer) strings at 4 bytes in each iteration, so if the "invalid" read
of 4 bytes at offset 48 into 51 bytes long buffer will read say
"ab\0" or "a\0" or "\0", then there is no invalid read at all - 
strchr knows that it can safely read those bytes as long as the pointer is
4 bytes aligned, which it is.

Comment 2 Jakub Jelinek 2005-07-06 21:45:44 UTC
No response, assuming my theory is correct.


Note You need to log in before you can comment on or make changes to this bug.