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

Summary: Invalid read reported by valgrind
Product: [Fedora] Fedora Reporter: Kjartan Maraas <kmaraas>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-07-06 21:45:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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.