Mercurial > pidgin.yaz
changeset 22401:d9105ead88dc
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.
| author | Evan Schoenberg <evan.s@dreskin.net> |
|---|---|
| date | Tue, 04 Mar 2008 00:11:22 +0000 |
| parents | d3c8fd63e296 |
| children | 75d53b0fae6c 86c18b2a16cc |
| files | libpurple/buddyicon.c |
| diffstat | 1 files changed, 5 insertions(+), 5 deletions(-) [+] |
line wrap: on
line diff
--- 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; }