[Guy Harris <gharris@xxxxxxxxxxxx>]

> I think that each protocol module should manage its own memory, just as the
> conversations stuff does now, but I think that there will be far more
> blocks of memory allocated than there are now.  For example, for the LanMan
> API, there is likely to be one or two conversations in a trace, with each
> conversation having 10 to 100 LanMan API calls and responses.  If the trace
> is even larger, and I have seen some large ones, then we may run out of
> space. 
> 
> I don't think we can easily reallocate a memory pool, and are faced with an
> expensive move operation if we run out of space.  Can anyone suggest any
> ideas?

Is the issue here that, by "manage its own memory, just as the
conversations stuff does now", you mean use the "g_mem_chunk" stuff, and
that if you read in a big capture file, and then close it and read in
another capture file, the first capture might've allocated a lot of
memory from one dissector's chunk, but the second capture might cause a
lot of stuff to be allocated from another dissector's chunk but not from
the first dissector's chunk, and that the first dissector's chunk might
then be tying up enough memory that's not being used but is also not
available to the second dissector?