On Thu, Oct 26, 2000 at 10:37:26PM -0700, Guy Harris wrote:
> You're assuming that Tethereal has no memory leaks. Apparently it does,
> but tracking the leak down could be difficult.
Or perhaps it's not a "leak" in the strict sense of the word; perhaps
various dissectors are allocating data for use when dissecting
subsequent frames (for example, ONC RPC replies and some SMB replies
don't have all the information needed to dissect the reply, so the
dissectors save some information about all requests, and try to match up
replies with the corresponding requests in order to get the missing
information) - said information isn't freed until the dissection of the
entire capture is complete.
That's the correct behavior for Ethereal, as you may dissect a given
reply many times; one could argue that Tethereal should arrange to free
the data up at some point (i.e., when you no longer expect to see
replies to the request for which the data was allocated), but that'd be
a non-trivial task.
If you run Tethereal with a read filter, the frames are dissected in
detail as they are read or captured, so that the read filter can be
applied to see whether to accept or reject the frame. If you run a live
capture in this fashion, the dissection of the entire capture isn't
complete until you stop the capture, so it just keeps allocating stuff.
If you have a lot of NFS traffic, or a lot of SMB "transaction"
requests, that could conceivably use up a lot of memory.
As such, when doing a live capture with Tethereal, "-f" (with a capture
filter) rather than "-R" (with a read filter) should be used whever
possible. (Capture filters have other advantages - they're much faster
to check, and, on many platforms, they're checked in the OS kernel, and
packets aren't even copied up to the application if they don't pass the
filter, which can cut CPU usage significantly.)