Bug 166018 - Invalid read of size 1 and crashes in different apps
Invalid read of size 1 and crashes in different apps
Status: RESOLVED DUPLICATE of bug 166145
Product: gtk-engines
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-engines maintainers
gtk-engines maintainers
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-02-02 10:01 UTC by Kjartan Maraas
Modified: 2005-02-03 10:52 UTC (History)
0 users

See Also:
GNOME target: 2.10.0
GNOME version: 2.9/2.10


Attachments

Description Kjartan Maraas 2005-02-02 10:01:39 UTC
When switching themes around a lot I often experience crashes in random apps,
including nautilus, gnome-panel, gnome-settings-daemon etc.

I've been running the theme manager under valgrind today and found the same
backtrace there with a warning about an "invalid read of size 1". This happened
while running the theme thumbnailer I think. Backtrace:

==756== Invalid read of size 1
==756==    at 0x1B90553A: strcmp (mac_replace_strmem.c:249)
==756==    by 0x1C25CE5D: IA__g_str_equal (gstring.c:69)
==756==    by 0x1C239C3E: IA__g_hash_table_lookup (ghash.c:203)
==756==    by 0x1C23584D: IA__g_quark_from_static_string (gdataset.c:592)
==756==    by 0x1CC5C1B6: smooth_rc_style_parse (smooth_gtk2_engine.c:75)
==756==    by 0x1BC4E639: gtk_rc_parse_style (gtkrc.c:3204)
==756==    by 0x1BC4EC85: gtk_rc_parse_any (gtkrc.c:2424)
==756==    by 0x1BC4F36B: gtk_rc_context_parse_one_file (gtkrc.c:827)
==756==    by 0x1BC4F451: gtk_rc_context_parse_file (gtkrc.c:893)
==756==    by 0x1BC4F635: gtk_rc_parse_named (gtkrc.c:644)
==756==    by 0x1BC4FA08: IA__gtk_rc_reparse_all_for_settings (gtkrc.c:1525)
==756==    by 0x1BC4FA68: gtk_rc_settings_changed (gtkrc.c:540)
==756==    by 0x1C201658: IA__g_cclosure_marshal_VOID__PARAM (gmarshal.c:531)
==756==    by 0x1C1ECD28: IA__g_closure_invoke (gclosure.c:437)
==756==    by 0x1C1FF949: signal_emit_unlocked_R (gsignal.c:2485)
==756==    by 0x1C2008CF: IA__g_signal_emit_valist (gsignal.c:2244)
==756==    by 0x1C200B1B: IA__g_signal_emit (gsignal.c:2288)
==756==    by 0x1C1EE7BA: g_object_dispatch_properties_changed (gobject.c:593)
==756==    by 0x1C1EDCC4: g_object_notify_dispatcher (gobject.c:234)
==756==    by 0x1C1F0B60: IA__g_object_set_valist (gobjectnotifyqueue.c:123)
==756==    by 0x1C1F0ED5: IA__g_object_set (gobject.c:1211)
==756==    by 0x805606A: message_from_capplet (theme-thumbnail.c:126)
==756==    by 0x1C268A8E: g_io_unix_dispatch (giounix.c:162)
==756==    by 0x1C245D70: IA__g_main_context_dispatch (gmain.c:1947)
==756==    by 0x1C24764E: g_main_context_iterate (gmain.c:2578)
==756==    by 0x1C2478CF: IA__g_main_loop_run (gmain.c:2782)
==756==    by 0x1BC19EB6: IA__gtk_main (gtkmain.c:963)
==756==    by 0x805717D: theme_thumbnail_factory_init (theme-thumbnail.c:609)
==756==    by 0x8050AA7: main (gnome-theme-manager.c:1441)
==756==  Address 0x1C63ACC8 is not stack'd, malloc'd or (recently) free'd

Marking this up and setting it on the 2.10.0 milestone since it's an important
fix for possibly a lot of crashes.
Comment 1 Matthias Clasen 2005-02-03 05:37:55 UTC
Vincent, the problem is that g_quark_new_from_static_string() puts the static
string in a global hash table without copying it. Bad things happen if the
memory holding the static string later becomes invalid when the engine is
unloaded...

The fix is to convert smooth to use g_quark_new_from_string() which copies the
string
Comment 2 Matthias Clasen 2005-02-03 05:46:48 UTC
Sorry, Kartan. You are not Vincent
Comment 3 Kjartan Maraas 2005-02-03 10:52:14 UTC
Thanks for clearing this up. Posted a patch in bug #166145

*** This bug has been marked as a duplicate of 166145 ***

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