Problem with memory leaks in Glade and GLADE

Problem with memory leaks in Glade and GLADE

[Dr. Adrian Wrigley]

Hi all!

I have got my client/server system running nicely now, based around
Annex E (GLADE 3.15p, RedHat Linux 7.3, Intel etc.), and around
GtkAda and GTK 2.2.  But there are two serious memory problems.

The GUI client (designed with Glade) consumes monotonically increasing memory.

Every second, I make a Set_Text call to display the current time:
Set_Text (UpdateRecord.Window.Time_Label, Image (Time.Functions.Now));

I make no attempt to free any associated memory.  Reading the documantation
on GtkAda, I am led to believe that the reference counting will ensure
this works OK.  The program consumes about 16kB *per second*, and
brought my server to a state of near collapse after less than a day :(
What am I doing wrong? (without the Set_Texts, memory usage is constant)

The Annex E server also consumes constantly rising memory.

In this case, each time a client partition connects and terminates,
the server partition grabs roughly another 200kB of memory.
My server code only allocates with "new" in one place, and
calls "Unchecked_Deallocation" shortly after.
I am puzzled by this, and suspect that the PCS may be leaking.
Any suggestions for tracing and solving this problem?

Overall, the combination of AnnexE and GtkAda is very nice for building
distributed, real-time, GUI-based applications.  But I do feel
rather "out on a limb" with these tools compared with acquantances
trying to do similar with (eg) Java.  Annex E seems to attract the interest
of a tiny minority of Ada uses, themselves a tiny minority of programmers.
I fear that Annex E use risks being below the critical mass needed to
get the interest of tool developers, language designers (Ada 0Y) etc.
To lose it would be a great shame and a lost opportunity :(

Your thoughts?
--
Dr Adrian Wrigley, Cambridge, UK.

Re: Problem with memory leaks in Glade and GLADE

[Stephen Leake]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> I have got my client/server system running nicely now, based around
> Annex E (GLADE 3.15p, RedHat Linux 7.3, Intel etc.), and around
> GtkAda and GTK 2.2.  

Congratulations!

> Every second, I make a Set_Text call to display the current time:
> Set_Text (UpdateRecord.Window.Time_Label, Image (Time.Functions.Now));
> I make no attempt to free any associated memory.  Reading the documantation
> on GtkAda, I am led to believe that the reference counting will ensure
> this works OK.  The program consumes about 16kB *per second*, and
> brought my server to a state of near collapse after less than a day :(
> What am I doing wrong? (without the Set_Texts, memory usage is constant)

I have not tried this, but perhaps Image is allocating a string that
you need to free? Try replacing the call to Image with a constant
string, just to see what happens.

Since GtkAda is based on Gtk, which is a very complex C program, all
kinds of things are possible :).

> The Annex E server also consumes constantly rising memory.
> 
> In this case, each time a client partition connects and terminates,
> the server partition grabs roughly another 200kB of memory.
> My server code only allocates with "new" in one place, and
> calls "Unchecked_Deallocation" shortly after.
> I am puzzled by this, and suspect that the PCS may be leaking.
> Any suggestions for tracing and solving this problem?

Try replacing the "new" and "Unchecked_Deallocation" with a stack
variable (just for testing, you can hard-code it; I assume you
actually _need_ the "new" in the real app). That will tell you whether
the Unchecked_Deallocation is actually deallocating.

-- 
-- Stephe

Re: Problem with memory leaks in Glade and GLADE

[Robert I. Eachus]

Dr. Adrian Wrigley wrote:

> The Annex E server also consumes constantly rising memory.
> 
> In this case, each time a client partition connects and terminates,
> the server partition grabs roughly another 200kB of memory.
> My server code only allocates with "new" in one place, and
> calls "Unchecked_Deallocation" shortly after.
> I am puzzled by this, and suspect that the PCS may be leaking.
> Any suggestions for tracing and solving this problem?

The 200kB size makes me suspect that a task is being created and the 
memory not freed.  The issue may be that the task control block is not 
being freed after the task is terminated.  This can happen either as a 
bug in the implementation, or because the task may still be named after 
it is terminated.  I suspect a combination of the two.  A task created 
of a task type in an outer scope.  (When you exit the scope in which the 
task was created, it is still live, but you may not be able to name it. 
  When it terminates, the  TCB and the task stack can be cleaned up--but 
there is no way for the creator to clean up afterward.  And the task 
itself may not know that it can no longer be named.)

> Your thoughts?
> -- 
> Dr Adrian Wrigley, Cambridge, UK.
> 



-- 
                                                        Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a
few minutes.  One thing he'd learned from Operation Beatrix: This field 
work wasn't for him. --from Red Rabbit by Tom Clancy.

Re: Problem with memory leaks in Glade and GLADE

[Dr. Adrian Wrigley]

I wrote:
...
> The GUI client (designed with Glade) consumes monotonically increasing 
> memory.
> 
> Every second, I make a Set_Text call to display the current time:
> Set_Text (UpdateRecord.Window.Time_Label, Image (Time.Functions.Now));

Unfortunately I have made little progress in solving the GtkAda problem,
other than identifying it as being more general than my specific code.

I have tried running the "testgtk" program supplied with GtkAda, and find
monotonic use of memory.

In particular, simply moving the pointer into the testgtk window consumes
a massive 52kB *each time*.  I can see the memory use rachet up simply by
moving the pointer in and out of the window.

Using any of the features sucks in more memory, for example, each time the
"Sheet" widget is used another 115kB disappears.

I can see why the writers of testgtk might not bother to free memory when
creating widgets, but it does give a bad impression to the casual user if
each time the pointer passes by another 52kB of memory is used.

The testgtk program is also convenient for seeing how to access the various
features of the interface, but if it is "incorrect" code because it
leaks like a sieve, it risks causing people serious trouble later.

I guess I should seek asistance on this topic on one of the mailing lists...

For the moment, I can tolerate restarting my GUI clients daily, during which
time, they don't manage to bring my system down. Much longer, and it hits
2GB process size or more, or runs out of total system memory+swap :(

Stephe wrote:
 > I have not tried this, but perhaps Image is allocating a string that you
 > need to free? Try replacing the call to Image with a constant string, just
 > to see what happens.

Thanks for the suggestion.  I tried the constant string, but the problem
remained the same. (my Image function doesn't allocate)

Thanks for listening!
-- 
Dr Adrian Wrigley, Cambridge, UK.

Re: Problem with memory leaks in Glade and GLADE

[Stephen Leake]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> I guess I should seek asistance on this topic on one of the mailing
> lists...

Yes. The GtkAda list is quite helpful. See
http://libre.act-europe.fr/GtkAda/ for info on how to subscribe (in
the Authors section).

-- 
-- Stephe

Re: Problem with memory leaks in Glade and GLADE

[Dr. Adrian Wrigley]

Stephen Leake wrote:
> Yes. The GtkAda list is quite helpful. See
> http://libre.act-europe.fr/GtkAda/ for info on how to subscribe (in
> the Authors section).

OK.  I've been looking at the list.  Useful to keep in touch with.

Unfortunately (?) I have found the leak problems are mirrored in the
C version of the demo code "gtk-demo".  This code also sucks in RAM each time
the pointed enters the main selection window, (as well as taking in
a megabyte or two extra each time a function is activated).

I can't blame deficient Ada programming for the behavior of gtk-demo,
and it almost looks like the "free" function call has been replaced by a no-op!

Perhaps the most obvious error I might have made would be to have some
inconsistent combinations of libraries being loaded, or versions with known
memory bugs, so (for the record) I've included the list below...

$ ldd /usr/local/bin/gtk-demo
         libgdk_pixbuf-2.0.so.0 => /usr/local/lib/libgdk_pixbuf-2.0.so.0 (0x40013000)
         libgdk-x11-2.0.so.0 => /usr/local/lib/libgdk-x11-2.0.so.0 (0x40027000)
         libgtk-x11-2.0.so.0 => /usr/local/lib/libgtk-x11-2.0.so.0 (0x40089000)
         libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402ab000)
         libXft.so.2 => /usr/lib/libXft.so.2 (0x402b8000)
         libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x402ca000)
         libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x402cf000)
         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x402f5000)
         libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4033e000)
         libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x40413000)
         libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40434000)
         libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40441000)
         libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40474000)
         libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x4048e000)
         libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x404c3000)
         libdl.so.2 => /lib/libdl.so.2 (0x404c7000)
         libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x404ca000)
         libm.so.6 => /lib/i686/libm.so.6 (0x40531000)
         libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
         libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40554000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
--
Adrian

Re: Problem with memory leaks in Glade and GLADE

[Jeff C,]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote in message
news:R15cb.2820$jJ3.43467@newsfep4-glfd.server.ntli.net...
> Stephen Leake wrote:
> > Yes. The GtkAda list is quite helpful. See
> > http://libre.act-europe.fr/GtkAda/ for info on how to subscribe (in
> > the Authors section).
>
> OK.  I've been looking at the list.  Useful to keep in touch with.
>
> Unfortunately (?) I have found the leak problems are mirrored in the
> C version of the demo code "gtk-demo".  This code also sucks in RAM each
time
> the pointed enters the main selection window, (as well as taking in
> a megabyte or two extra each time a function is activated).


Not sure this is applicable but I remembered seeing something about the glib
free routines

http://docs.linux.cz/gtk-faq/x672.html

Why does GTK+/GLib leak memory?
It doesn't. Both GLib and the C library (malloc implementation) will cache
allocated memory on occasion, even if you free it with free().

So you can't generally use tools such as top to see if you are using free()
properly (aside from the very roughest of estimations, i.e. if you are
really, really screwing up top will show that, but you can't distinguish
small mistakes from the GLib/malloc caches).

In order to find memory leaks, use proper memory profiling tools.

Re: Problem with memory leaks in Glade and GLADE

[Dr. Adrian Wrigley]

Dr. Adrian Wrigley wrote:
> I wrote:
> ...
> 
>> The GUI client (designed with Glade) consumes monotonically increasing 
>> memory.
>>
>> Every second, I make a Set_Text call to display the current time:
>> Set_Text (UpdateRecord.Window.Time_Label, Image (Time.Functions.Now));

This problem has been solved, with help from Dave Hill.

The leak is in Xft-2.0-1 (not an Ada/GtkAda problem at all!)

The full explanation is on the RedHat site:
https://rhn.redhat.com/errata/RHBA-2002-305.html

The leak was triggered because I was using VNC, which lacks the X RENDER extension.
This explains how other users hadn't seen this problem.

Thank you Dave for helping solve this mystery!
--
Adrian