pidgin.next.minor: 88d15a78: g_hash_table_ref() / g_hash_table_unref(..
evan.s at dreskin.net
Wed Apr 30 17:02:53 EDT 2008
On Apr 30, 2008, at 2:47 PM, Mark Doliner wrote:
> I haven't tested this or dug around very much, but wouldn't this
> crash? It
> looks like you're not actually copying the data but instead just
> references to the strings in the original hash table, which are
> freed by
> whoever called serv_join_chat().
Yeah, you're right. It worked in my testing, but it's not reliable
memory management. I'm used to working in code in which everything
automatically has reference counting, so adding an object to a
dictionary which retain it without question... I'll fix it right now.
Thanks for the catch.
> I'm also wondering if it would be better if
> the core gave the hash table to the PRPL and it was the PRPLs
> to free it. But I guess that might require an API change (or we
> could just
> live with the fact that 3rd party PRPLs would leak memory until they
> freeing the hash table).
I think it's much more straightforward when ownership of objects
doesn't change with calls; changing ownership would avoid allocation
of a second set of objects, but the result would be that any code
calling serv_join_chat() would need to remember not to free the
GHashTable it had created, which feels awkward to me.
More information about the Devel