memdebug.[ch]

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

> I hate it when the wrong keystroke sends a message that's only half
> composed.  However, as I was saying:
>
> Memdebug needs some bookkeepping information for each memory block it
> works with.  This information is put at the beginning of the block and
> the block's address is adjusted so that bogofilter gets a pointer to
> memory it can change.  The information is used when the block is
> freed.  The info could be stored separately from the memory block, but
> that would be time consuming and would impose a noticeable speed penalty.
>
> Looking in database_db.c there are places where BerkeleyDB allocates
> storage and bogofilter must free it.  As these allocations aren't seen
> by memdebug, the deallocations can't be done by memdebug.  This means
> that the deallocations must be done via direct call to glibc's free()
> function and that means that memdebug can't co-opt free().  That leaves
> matters where they now are -- memdebug must use xfree as its hook.

All this should have been answered by the mail whose transit time
crossed with yours.

> Given this situation, please humor my wish to keep bogofilter
> compatible with memdebug and leave the few extra calls to xfree(), even
> though each one uses several machine cycles.

I'll consider doing that if Berkeley DB's set_alloc turns out to /not/ cut
the mustard.

> At present, bogofilter has only 1 memory block that is allocated but
> not freed.

I'd be curious to know which one - boehm-gc hasn't complained in
leak-check mode a few minutes ago, so this must be memory that still has
pointers left at program exit, to be released by _exit().

> I'm about to see if the count can be reduced to zero.

Don't waste your time unless it's a large block or something that falls
unreferenced.

-- 
Matthias Andree
_______________________________________________
Bogofilter-dev mailing list
Bogofilter-dev at bogofilter.org
http://www.bogofilter.org/mailman/listinfo/bogofilter-dev