From 47b5514af1101a64fcf220056c7e4a81d89aeeb9 Mon Sep 17 00:00:00 2001 From: Ted Gould Date: Tue, 1 Mar 2011 21:12:03 -0600 Subject: Delaying the removal from the hashtable. --- libdbusmenu-glib/menuitem.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/libdbusmenu-glib/menuitem.c b/libdbusmenu-glib/menuitem.c index 399b6f5..f7867e4 100644 --- a/libdbusmenu-glib/menuitem.c +++ b/libdbusmenu-glib/menuitem.c @@ -1182,6 +1182,7 @@ dbusmenu_menuitem_property_set_variant (DbusmenuMenuitem * mi, const gchar * pro gboolean replaced = FALSE; + gboolean remove = FALSE; gpointer currentval = g_hash_table_lookup(priv->properties, property); if (value != NULL) { @@ -1196,10 +1197,21 @@ dbusmenu_menuitem_property_set_variant (DbusmenuMenuitem * mi, const gchar * pro gchar * lprop = g_strdup(property); g_variant_ref_sink(value); - g_hash_table_replace(priv->properties, lprop, value); + /* Really important that this is _insert as that means the value + that we just created in the _strdup is free'd and not the one + currently in the hashtable. That could be the same as the one + being passed in and then the signal emit would be done with a + bad value */ + g_hash_table_insert(priv->properties, lprop, value); } else { if (currentval != NULL) { - g_hash_table_remove(priv->properties, property); + /* So the question you should be asking if you're paying attention + is "Why not just do the remove here?" It's a good question with + an interesting answer. Bascially it's the same reason as above, + in a couple cases the passed in properties is the value in the hash + table so we can avoid strdup'ing it by removing it (and thus free'ing + it) after the signal emition */ + remove = TRUE; replaced = TRUE; } } @@ -1220,6 +1232,10 @@ dbusmenu_menuitem_property_set_variant (DbusmenuMenuitem * mi, const gchar * pro g_signal_emit(G_OBJECT(mi), signals[PROPERTY_CHANGED], 0, property, signalval, TRUE); } + if (remove) { + g_hash_table_remove(priv->properties, property); + } + return TRUE; } -- cgit v1.2.3