Re: [Ethereal-users] Ethereal Not Releasing Memory

[Guy Harris <gharris@xxxxxxxxx>]

On Tue, Jun 29, 2004 at 03:11:08PM -0700, Jeffrey S Korpa wrote:
> I've got the latest and greatest version of Ethereal for Solaris 
> (ethereal-0.10.4-solaris2.9-sparc-local.bz2) installed on a SunBlade 2000 
> running Solaris 9 here at work, and have noticed that if I open a large 
> capture file, then close it, Ethereal does not release the memory it used 
> back to the operating system.

Few, if any, applications do so.  The standard system "malloc()" on, as
far as I know, most if not all UN*Xes (and possibly the standard C
library "malloc()" with MSVC++ on Windows as well), will increase the
size of the system heap if it can't get the memory from its free memory
pool, but the standard system "free()" (and possibly the standard C
library "free()" with MSVC++ as well) won't return memory to the system,
it'll just add it to its free memory pool.

However, that memory *should* get released to "malloc()"s free memory
pool, and thus should, modulo fragmentation, be used by subsequent
"malloc()" calls.

In addition, GLib (and thus GTK+), and Ethereal, maintain some of their
own memory pools for various data structures (to avoid "malloc()"
overhead); when that memory is freed, it's released back to the memory
pool in question, and would be reused only for that data structure,
which trades off one form of fragmentation (the freed memory is
*guaranteed* to be usable for that data structure) for, arguably,
another (it can't be used for other data structures).

> If I open and close multiple capture files, the situation only gets
> worse.

The subsequent capture files should be able to reuse most of the freed
memory, although if the new capture file is larger, it'll require more
memory, and if it uses memory sufficiently differently, some of the
freed memory might not be usable for the new capture, so the new capture
file might require more memory than the previous one even if it's not
bigger.