Ethereal-dev: Re: dcerpc patch (was Re: [Ethereal-dev] Is someone working on a DCOM/ORPC disse
On Mon, Jul 09, 2001 at 08:03:02AM -0400, Todd Sabin wrote:
> Could someone double-check the conversation/hash stuff for leaks? I
> used pretty much the same approach used by packet-rpc.c,
But not exactly the same approach.
The ONC RPC dissector allocates rpc_call_info_key and
rpc_call_info_value structures from a GLib "memory chunk"; memory chunk
items are mallocated "in bulk" - the memory chunk code allocates items
in chunks containing multiple items, and parcels the items out
individually. It maintains its own free lists of items, as well as a
list of chunks.
This means that
1) allocating an item is cheaper, as the memory chunk code only
calls "g_malloc()" if it has no free items, and a single call
to "g_malloc()" allocates enough space for N items;
2) the malloc overhead is amortized over N items, saving some
memory;
3) you can free all the items allocated from a memory chunk in
one call, and that call frees entire chunks, so there's one
call to "g_free()" for every N items.
"rpc_init_protocol()" not only destroys and reallocates the hash tables,
it also destroys and reallocates the memory chunks, so that the hash
tables *and* the keys and values are freed.
The patched DCE RPC dissector didn't appear to be freeing any of the
keys - destroying a hash table *doesn't* free up the keys (and *can't*,
as they could be statically-allocated data structures, for example).
I'd suggest allocating the call keys and values, UUID keys and values,
and conversation keys and values from memory chunks, and destroying and
recreating the chunks in "dcerpc_init_protocol()".
("dcerpc_init_protocol()" doesn't destroy and recreate the UUID hash
table; is the theory here that the first "U" stands for "unique" so that
there's no reason to destroy the table just because you're processing a
different capture?)
