After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 614660 - [StThemeNode] Squash epic memory leak
[StThemeNode] Squash epic memory leak
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2010-04-02 13:40 UTC by Colin Walters
Modified: 2010-04-06 01:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[StThemeNode] Squash epic memory leak (2.23 KB, patch)
2010-04-02 13:40 UTC, Colin Walters
needs-work Details | Review
[StThemeNode] Squash epic memory leak (2.72 KB, patch)
2010-04-03 15:28 UTC, Colin Walters
committed Details | Review

Description Colin Walters 2010-04-02 13:40:19 UTC
See patch.
Comment 1 Colin Walters 2010-04-02 13:40:21 UTC
Created attachment 157752 [details] [review]
[StThemeNode] Squash epic memory leak

StThemeNode holds a reference to its parent, but we never released
that reference.  This could cause us to hold onto whole chains
of theme nodes with rather dire memory usage implications.

Also move the other g_object_unref into _dispose.
Comment 2 Owen Taylor 2010-04-03 12:14:43 UTC
Review of attachment 157752 [details] [review]:

The finalize/dispose split here doesn't seem necessary to me - ThemeNodes are simple data structures, and shouldn't have signals etc and shouldn't participate in refcount cycles. And we don't g_object_run_dispose() dispose the theme node in st_widget_dispose(), before unreffing it. But it is also harmless.

You missed one of the three things ref'ed in the constructor - node->theme. (Which has an inconsistency in two code paths as to whether it is ref'ed or not, so that needs fixing too)
Comment 3 Colin Walters 2010-04-03 15:26:31 UTC
(In reply to comment #2)
> Review of attachment 157752 [details] [review]:
> 
> The finalize/dispose split here doesn't seem necessary to me - ThemeNodes are
> simple data structures, and shouldn't have signals etc and shouldn't
> participate in refcount cycles. And we don't g_object_run_dispose() dispose the
> theme node in st_widget_dispose(), before unreffing it. But it is also
> harmless.

I'd prefer to keep the dispose; helps me be consistent for when it is needed.

> You missed one of the three things ref'ed in the constructor - node->theme.
> (Which has an inconsistency in two code paths as to whether it is ref'ed or
> not, so that needs fixing too)

It looks to me like it's always referenced.
Comment 4 Colin Walters 2010-04-03 15:28:17 UTC
Created attachment 157827 [details] [review]
[StThemeNode] Squash epic memory leak

StThemeNode holds a reference to its parent, but we never released
that reference.  This could cause us to hold onto whole chains
of theme nodes with rather dire memory usage implications.

Also move the other g_object_unref into _dispose.
Comment 5 Owen Taylor 2010-04-05 19:52:55 UTC
Review of attachment 157827 [details] [review]:

Looks fine
Comment 6 drago01 2010-04-06 01:00:46 UTC
(In reply to comment #5)
> Review of attachment 157827 [details] [review]:
> 
> Looks fine

No, this seems to cause lots of 
g_object_ref: assertion `G_IS_OBJECT (object)' failed
and
g_object_unref: assertion `G_IS_OBJECT (object)' failed

random elements to have no style applied and even a crash.

The previous version was fine.
Comment 7 Colin Walters 2010-04-06 01:10:02 UTC
Ok, i see the probable bug here:


diff --git a/src/st/st-theme-node.c b/src/st/st-theme-node.c
index 6d37d60..d742c6b 100644
--- a/src/st/st-theme-node.c
+++ b/src/st/st-theme-node.c
@@ -47,7 +47,7 @@ st_theme_node_dispose (GObject *gobject)
   if (node->theme)
     {
       g_object_unref (node->theme);
-      node->context = NULL;
+      node->theme = NULL;
     }
 
   if (node->parent_node)