# HG changeset patch
# User Evan Schoenberg <evan.s@dreskin.net>
# Date 1204589482 0
# Node ID d9105ead88dc041f94791dfbc884eeff5c3ba9a5
# Parent  d3c8fd63e296825b42544749ce572d9bb595d60b
When purple_buddy_icons_set_account_icon() is called, it unrefs the old PurpleStoredImage and refs the new one.  Previously, it notified the prpl of the change in the buddy icon before updating pointer_icon_cache, which meant that if the prpl then called purple_buddy_icons_find_account_icon() it would get the old PurpleStoredImage (which is at this point not only old but also a pointer to invalid memory if unref'ing it caused it to be destroyed).  This happens in jabber_set_info() as of 2.4.0, causing a crash when setting no-buddy-icon for an account after it has previously had an icon. I think this also means that XMPP accounts in 2.4.0 will also always set serverside the *last* icon set, not the current one, when changing icons, but I didn't test that.
The solution is simple: Update pointer_icon_cache earlier, setting the new img if there is one or removing the account entirely from the hash table if there isn't one now.  This fixes both problems described above, making purple_buddy_icons_find_account_icon() return the new, current icon (or NULL) at all times.

diff -r d3c8fd63e296 -r d9105ead88dc libpurple/buddyicon.c
--- a/libpurple/buddyicon.c	Mon Mar 03 21:44:40 2008 +0000
+++ b/libpurple/buddyicon.c	Tue Mar 04 00:11:22 2008 +0000
@@ -701,6 +701,11 @@
 	}
 	unref_filename(old_icon);
 
+	if (img)
+		g_hash_table_insert(pointer_icon_cache, account, img);
+	else
+		g_hash_table_remove(pointer_icon_cache, account);
+	
 	if (purple_account_is_connected(account))
 	{
 		PurpleConnection *gc;
@@ -724,11 +729,6 @@
 	}
 	g_free(old_icon);
 
-	if (img)
-		g_hash_table_insert(pointer_icon_cache, account, img);
-	else
-		g_hash_table_remove(pointer_icon_cache, account);
-
 	return img;
 }