While I was trying to iron out the small memory leaks I seem to have
introduced over some time to the dg script package, my memory allocation
checker told me about one huge chuck of unfreed memory on shutdown.
This pertains to the pool of large buffers, bufpool, in comm.c.
These buffers are never free'd.
Also, there was a host of small memory allocations in mail.c, related
to the in-memory mail_index.
I suggest a solution along these lines:
...
if (!scheck) {
log("Clearing other memory.");
+ free_bufpool(); /* comm.c */
free_player_index(); /* db.c */
free_messages(); /* fight.c */
clear_free_list(); /* mail.c */
+ free_mail_index(); /* mail.c */
...
void free_bufpool(void)
{
struct txt_block *tmp;
while (bufpool) {
tmp = bufpool->next;
if (bufpool->text)
free(bufpool->text);
free(bufpool);
bufpool = tmp;
}
}
in mail.c:
void free_mail_index(void)
{
mail_index_type *tmp;
while (mail_index) {
tmp = mail_index->next;
if (mail_index->list_start) {
position_list_type *i, *j;
i = mail_index->list_start;
while (i) {
j = i->next;
free(i);
i = j;
}
}
free(mail_index);
mail_index = tmp;
}
}
Some may say this is a moot point, since it's only freeing
the memory just before the program ends. However, memory debugging
is a lot harder, when you get results like this:
zmalloc: UNfreed memory 0x824fe80 12 bytes mallocd at comm.c:1242
zmalloc: UNfreed memory 0x824fee0 24448 bytes mallocd at comm.c:1243
...
zmalloc: 44 leaks totalling 25016 bytes... you must work for Microsoft.
After this I was down to
zmalloc: 10 leaks totalling 240 bytes... close, but not there yet.
Oh, yes - and some multiple free()'s :(
Welcor
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/26/03 PDT