Ethereal-dev: Re: [ethereal-dev] Further thoughts on Per Frame state information
At 12:42 PM 2/19/00 -0800, Guy Harris wrote:
>> 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?
Well, not quite.
I expect each dissector that cares to have an initialization routine that
is called when a file is read in. It would use the g_mem_chunk stuff when
called and should free any memory already allocated.
But, what do you do when you have exhausted the memory allocated with the
g_mem_chunk call? Do you simply stop associating state with frames?
It is very hard to reallocated the chunk, because you have to track down
the pointers to blocks within your chunk and update them and so on. It is
easier to allocate a new chunk, but then you have to do management of the
chunks, and I do not know if the g_mem_chunk stuff gives you any help here.
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx, Master Linux Administrator :-),
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Co-author, SAMS Teach Yourself Samba in 24 Hours
Author: First Australian 5-day, intensive, hands-on Linux SysAdmin course
Author: First Australian 2-day, intensive, hands-on Samba course
