hexchat/hexchat — pull request #114 by RichardHitt (2012-10-01 05:16:20+00:00)
Title: Fix memory leak related to url grabbing

Hexchat, like xchat, uses src/common/tree.c to keep lists of usernames
(one list per session) and urls (one list for the whole app).
Usernames are kept in sorted order. Urls were kept in sorted order,
too, through svn revision 1501; with 1502, urls are kept in FIFO order.
(Don't be fooled by the name 'tree'; each list is really an array.)

This change to FIFO order for urls broke duplicate checking, because that
was still done using a binary search, in tree_find(); and of course you
can't binary-search a FIFO-ordered list.

So, beginning with revision 1502, the list of urls can grow indefinitely
large. Most of them are in fact duplicates. In a long-running process of
mine, hexchat had accumulated over half a million urls! (514,172 to be
exact). Doing a sort -u on the file gave only twenty thousand (20,374).
That's a forty-day accumulation, and I consider it reasonable.

Revision 1502 also added limiting code and parameter url_grabber_limit.
But in implementing this (in url_add()), code to shrink the array size
did not free the url strings. This is a true memory leak, but it would
only occur when url_grabber_limit was changed from its default of 0.

As a fix, I have done url duplicate detection entirely in url.c, by adding
a GTree and the usual lines to add, search, delete; it took surprisingly
little code. I have restored the default of url_grabber_limit to 0; it
had been changed to 50 when the problem was insufficiently understood.
In tree.c I have made tree_remove_at_pos() return the pointer just
removed, so that url_add() can free its storage.