relson at osagesoftware.com
Tue Mar 15 20:48:36 EST 2005
On Tue, 15 Mar 2005 20:04:28 -0500
David Relson wrote:
> I'm working on changing memdebug's hooks from xmalloc, et all to
> malloc,... and have run into a snag. For reasons that aren't yet
> clear, datastore_db.c is bombing in db_close() at line:
> ret = dbp->close(dbp, flag);
> Until I figure out what's happening, the hooks aren't changeable.
> By the way, making datastore_sqlite.c compatible with memdebug was how
> I discovered the strdup/xstrdup inconsistency.
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.
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.
At present, bogofilter has only 1 memory block that is allocated but
not freed. I'm about to see if the count can be reduced to zero.
Bogofilter-dev mailing list
Bogofilter-dev at bogofilter.org
More information about the Bogofilter-dev