Bug 159701 - Invalid read reported by valgrind
Invalid read reported by valgrind
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-07 04:54 EDT by Kjartan Maraas
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-06 17:45:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kjartan Maraas 2005-06-07 04:54:45 EDT
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 12:11:43 EDT
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 17:45:44 EDT
No response, assuming my theory is correct.

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