Wireshark · Ethereal-dev: RE: [Ethereal-dev] Memory leak of ethereal-0.8.12

["Reimer, Fred" <Fred.Reimer@xxxxxxxxxxxx>]

I'm not sure I understand you.  It was my understanding that the process
size SHOULD grow while it captures traffic.  Doesn't it keep all the
captured packets in memory?  How could it stay the same size if it did keep
them in memory?  You'd have to pre-allocate huge amounts of memory that you
may not even use, as you could just be loading up Ethereal to load in a five
packet capture someone sent you.  I think this is normal behavior.

Now, it does bring up a different issue.  While I was analyzing a 60MB
capture file for work I noticed that, on my Windows 2000 box, Ethereal took
up about 144MB (or somewhere around there, definitely more than 100MB).  I
have 256MB on my computer, so it only thrashed a little (NT takes up loads
of memory just for the OS).  But, what would be the possibility of keeping
the packets on disk until they are needed?  I don't think you'd be able to
do this with compressed files, but I'd be more than willing to "uncompress"
compressed captures temporarily if it would drastically reduce the memory
footprint.  In order to effectively work with large captures I have to put
them on my SPARC box with 2GB memory.  This seems to be an excessive
requirement.

I was thinking that Ethereal could "prescan" capture files and create a
linked list of info records for each packet in the file, probably containing
nothing other than the offset in the file where the packet starts.  If the
size of the packet capture is known, you probably wouldn't even need a
linked list and could use a standard array.  Then Ethereal could read in the
packets it needs to decode for the display and quickly jump to a given
offset in the file for a given packet number.  To handle display filters, a
second array could be kept that listed the offsets of packets that passed
the current filter, and store a -1 or zero or some other flag if the packet
didn't pass the filter.

Either that or simply keeping a cache of a reasonable size, say 16-32MB,
that "close" packets in relation to what is actively being displayed, would
help.  Something needs to be done so that large packets traces can be
handled.

Is this really needed?  I think so.  Some might argue that you should put in
a capture filter to narrow down what you are tracing, as you surely are not
looking at every frame in a 100MB trace.  But, sometimes we don't have
control over what is captured.  Some clients will just capture everything
even if they do know what the MAC or other distinguishing characteristic is.
Some clients WANT all packets so that we can do a sort of "network analysis"
for them and just look for issues.  You'd be surprised, or may be not, how
many issues can be identified just by looking at the broadcast traffic on a
network.  So I say yes, there is a need, even if it's not an every-day
thing, to be able to decode huge packet traces.

What do you think?  Too much work/trouble?  Not worth it?  Just plain
stupid?  Not possible given the current architecture of Ethereal?

Fred Reimer
Eclipsys Corporation

> -----Original Message-----
> From: ethereal-dev-admin@xxxxxxxxxxxx
> [mailto:ethereal-dev-admin@xxxxxxxxxxxx]On Behalf Of Harald Tveit
> Alvestrand
> Sent: Friday, October 13, 2000 7:30 AM
> To: ethereal-dev@xxxxxxxx
> Subject: [Ethereal-dev] Memory leak of ethereal-0.8.12
> 
> 
> Is it a known bug that Ethereal 0.8.12 leaks memory?
> 
> I discovered it while wondering why Ethereal was so slow 
> after capturing 
> packets continuously for 3 days on a 486/66 with 40 Mbytes of 
> memory.....call me weird, but I like watching.
> The program size was 40 Mbytes, resident 17 Mbytes; just 
> after start, the 
> program size was 5.9 Mbytes (as reported by ps -aux).
> 
> - OS: Linux 2.2.5 with SMP support, from Red Hat 6.0 distribution
> - GTK: 1.2.6
> - Ethereal 0.8.12 with GTK+ 1.2.6, with libpcap 0.4, without 
> libz, without SNMP
> - Command used: Start Ethereal with a remote display to 
> another X server,
> display options "Time of day", select "automatic scrolling in 
> live capture" 
> and "enable name resolution". Capture length 65535.
> Start capture with a "not host <X server>" packet filter.
> - Leave to stew for 3 days on a home LAN (low traffic).
> 
> If this is a well known problem, I'll wait for the next version of 
> something... otherwise, I'm happy to try out patches and let 
> the thing run.
> 
> --
> Harald Tveit Alvestrand, alvestrand@xxxxxxxxx
> +47 41 44 29 94
> Personal email: Harald@xxxxxxxxxxxxx
> 
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>