On Fri, Jun 06, 2003 at 04:54:17PM +0200, "B. Lo�c" wrote:
> I read the doc/README.design : it says that when using a capture file,
> every frame has an associated frame_data struct, with pointers to
> previous and next frames. I looked at the source, saw calls to
> clear_fdata(), saw comments saying that a live capture isn't saved
> anywhere... Thus, I really don't understand why memory usage is
> increasing like that.
>
> Did I miss a point in the design of tethereal that would explain this ?
> Or is this some kind of memory leak ?
It's not an either/or situation.
Tethereal, unlike Ethereal, doesn't allocate a frame_data structure for
every packet, as it doesn't support going back and looking at packets
once the packet's data is printed.
However, some dissectors allocate data to remember information about
some packets; for example, for ONC RPC and DCE RPC requests, enough
information is saved to allow the matching reply to be decoded (requests
contain an operation number, but replies don't, so you need the matching
request to know the type of request to which it's a reply). That
information is currently not freed when the dissector doesn't need it
any more. In order for the dissector to do so:
1) it would need to know when it doesn't need it any more (and,
in some cases, it might be hard for the dissector to
determine that, as the first time it uses that information
might not be the last time it uses it);
2) it would need to know whether it's running inside an
application that allows packets to be re-visited (Ethereal,
Zethereal, Packetyzer, etc.) or doesn't allow packets to be
re-visited (Tethereal).
One place where information is remembered is the reassembly code used by
various dissectors. At least in Tethereal, the memory used by that code
to save information about the reassembled packet, and the data in the
reassembled packet, could, I think, be discarded when the reassembled
packet is processed. (The data could even be freed in Ethereal, I
think, if we can make random access to gzipped captures fast, as,
instead of saving the packet data, we'd just save enough information to
retrieve the data from the frames in the file, and we'd re-read the
packet data and reassemble the data on subsequent references to the
packet.)
However, none of that says that all forms of "persistent" memory in
Tethereal are supposed to be persistent; there could also be
unintentional memory leaks in dissectors (or, conceivably, in the
Tethereal core itself).