PR# 3968 Memory leaks in Vision2

There are memory leaks in Vision2.  Not sure if they are in the Eiffel
code or in GTK+2.x itself.  Sample test program attached.  The Eiffel and
C memory stays constant for 500 iterations, but the heap size keeps growing
(as shown by "pmap <process_id> | fgrep -i heap").

Even a program that creates a window and just keeps changing its position
via `set_position' leaks memory.

This is very discouraging.  I assumed that all the memory leaks would be
fixed by the time Vision2 got onto GTK+2.x.

See above.

Suspending for now as the bug is situated in gtk, will remove when a solution to the problem has been identified.

I've narrowed down this memory leak to gtk and sent a message to their mailing list to see if I get a good reply.  It looks like the bug relates to asynchronous X11 calls and this memory is not being freed.  Running with dbx using 'check -memuse' shows the info below, this may or may not be related to the heap growing but it is certainly odd that so much memory is being allocated by this particular function call.  Truss also reports 8 continuous brk system calls per iteration.

 Total    % of Num of  Avg    Allocation call stack
 Size      All Blocks  Size
========== ==== ====== ======  =======================================
 10222888  69%  98297    104  _XEnq < _XReply 

The following C code exhibits the continuous growth of the heap.

#include <gtk/gtk.h>

int main( int   argc,
          char *argv[] )
{
    /* GtkWidget is the storage type for widgets */
    GtkWidget *window;
    GtkWidget *event_box;

    /* This is called in all GTK applications. Arguments are parsed
     * from the 
....
Output truncated, Click download to get the full message

I don't think this is a GTK problem.  Here is a very simple system that
just repeatedly calls `wipe_out' on an EV_TITLED_WINDOW, creates an EV_LABEL
and then calls {EV_TITLED_WINDOW}.extend, passing the label.  When executed,
the system uses more and more memory (in the heap).  It looks like maybe
the label is not garbage for some reason, though from my point of view it is,
and hence is not garbage collected until the final reclaim.

I tried this system with GTK+2.10.1 at home and it still would eventually
run out of memory (no difference from GTK+2.4).

Please look at this simple example and either tell me what dumb thing I'm
doing wrong or find and fix the problem for 5.7.

Yes,the memory leaks are still there.  However, I should point out that
according to MEM_INFO, no Eiffel or C memory is leaked.  But the heap
keeps growing, as shown by "pmap PROCESS_ID | fgrep -i heap".  This
indicates to me that the leak may be in GTK itself (GTK+2.4 in this case,
though I suspect the problem exists in 2.6 as well).  This may make it
hard to fix.  In my experience, every version of GTK has fixes for
memory leaks listed in the release notes.
 

Is this still the case?

State-Changed-From-To: open-analyzed
State-Changed-By: Manu
State-Changed-When: Fri Aug 20 13:57:22 PDT 2004
State-Changed-Why:

Dear David,

We are looking into the memory leaks. There is one thing that you need
to know is that there will always be a memory leak until we are able
to reuse some of the internal IDs used by vision2. Indeed we use the
IDENTIFIED class and each time you allocate 1000 vision2 objects (even
if they are all dead), then we looses 4008 bytes of data that cannot
be reused in any way.

We are trying to find how much is related to the IDENTIFIED class to 
ensure that only this remains. Then it will be a matter of creating
a new abstraction that enables the reuse of dead IDs.