Re: [PHP-GTK] Freeing up memory when objects drop out of scope
by Andrei Zmievski other posts by this author
Aug 5 2006 11:16AM messages near this date
[PHP-GTK] Freeing up memory when objects drop out of scope
|
Re: [PHP-GTK] Freeing up memory when objects drop out of scope
Sorry for a delayed reply.
> So I'm still bashing my head against a nasty memory leak that's
> been plaguing me
> for the past few months. The program contains a manager class that
> oversees
> several small, customizable "screen content" classes. Each screen
> has its own
> load of assorted widgets, containers, and pixmaps, which are all
> shoved into a
> box which is inserted into the page. When the user navigates from
> one screen to
> the other, the manager destroys the old screen content object and
> creates the
> next one in the list. The problem is that my program is leaking
> substantial
> memory per "screen swap" (anywhere from 120k-8mb(!!!)) depending on
> the page.
> I've had several people go over my code and it doesn't have any
> apparent memory
> leaks.
What kind of object is this "screen"? GtkWindow?
> I guess my question is how do I _know_ that when the object is
> "destroyed" all
> of its internal memory is freed properly? Shouldn't the screen
> drop out of
> scope and free up all the memory it used when I navigate away from
> it? I don't
> think there are any other references to a page aside from the
> object itself (via
> $this) and the manager class. Could it be the page is being freed,
> but the
> internal objects are still floating around in memory?
Yes, and this is by design (for some objects). Most of the objects
like GtkButton, etc will be auto-destructed once they drop out of
scope. However, there is a handful (like GtkWindow, and others which
I can't remember now) that behave differently. These objects may have
internal references held to them from parts of Gtk+. So when a
GtkWindow drops out of scope, we check whether the refcount > 1 and
if so, we make the internal GtkWindow object "own", that is, hold a
reference to its wrapper. Then, if the refcount on the wrapper or the
internal object is decreased further, everything is cleaned up.
Basically, you shouldn't really worry about memory management in PHP-
GTK aside from being aware of this issue.
> I've even tried the
> following
>
> $this->memvar1 = NULL;
> $this->memvar2 = NULL;
> ..
> $this = NULL;
> (where each variable (including GTK objects) is a member variable
> (in the manager class)
> unset($this->screenvar);
> $this->screenvar = NULL;
>
> .. and it still leaks the same amount of memory! Is there some
> obscure
> referencing issue that I'm not aware of, like passing objects by
> reference
> creating local copies or not freeing up memory?
Did you try $this-> screenvar->destroy()?
-Andrei
--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Thread:
Andrew Buczacki
Andrei Zmievski
Andrew Buczacki
Andrei Zmievski
Christian Weiske
Andrew Buczacki
Christian Weiske
|