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 733327 - Polari is Leaking Huge Amounts of Memory
Polari is Leaking Huge Amounts of Memory
Status: RESOLVED OBSOLETE
Product: polari
Classification: Applications
Component: general
3.12.x
Other Linux
: Normal major
: ---
Assigned To: Polari maintainers
Polari maintainers
Depends on:
Blocks:
 
 
Reported: 2014-07-17 16:06 UTC by Antoine Saroufim
Modified: 2021-06-10 11:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
xrestop: polari beats firefox by an order of a magnitude (69.56 KB, image/png)
2015-07-15 13:45 UTC, Matthias Clasen
  Details
Valgrind log (51.35 KB, application/x-tar)
2015-07-22 10:48 UTC, Hussam Al-Tayeb
  Details
chatView: Always dispose cairo context (2.02 KB, patch)
2015-07-30 01:26 UTC, Florian Müllner
committed Details | Review

Description Antoine Saroufim 2014-07-17 16:06:38 UTC
After using Polari for 4-5 hours, it starts leaking about 700~ MiB of memory. It can go up to 1.2 GiB. Once restarted, Polari would stop leaking memory for a few hours. 
I'm on openSUSE 13.1 with GNOME 3.12.
Comment 1 Dominique Leuenberger 2014-10-09 16:12:06 UTC
One way to make it leak:
- Have more than one room connected
- On each switch between a room, it consumes between 30 to 50 MB more memory.
At least here, this happens 'immediately' after start and switching between rooms is a reliable way to trigger a big leak (and I can imagine that a common use is reading the content of the different rooms, quickly summing up for huge amounts of memory)
Comment 2 Dominique Leuenberger 2014-10-09 16:20:13 UTC
In git master, at least the leak while switching rooms is gone (likely due to the changes with not populating/creating the user list widgets and user details).

so, one down.

Another reliable way, though, to still trigger a memory bump is for polari to:
- lose focus
- regain fofucs (surprisingly this one mainly seems to happen when switching between polari and gnome-system-minitor; when switching between polari and gnome-terminal, I don't see it)
Comment 3 Matthias Clasen 2015-07-15 13:43:42 UTC
There's a lot of constant drawing going on in polari, and it appears to be leaking X pixmaps, from what xrestop tells me (see screenshot). It is a bit curious that I does seem to get cleaned up every once in a while - in gnome-system-monitor, you can see the "X memory" column grow rapidly up to several gig, and then fall back to ~150M every so often.
Comment 4 Matthias Clasen 2015-07-15 13:45:14 UTC
Created attachment 307479 [details]
xrestop: polari beats firefox by an order of a magnitude
Comment 5 Florian Müllner 2015-07-16 21:05:04 UTC
(In reply to Matthias Clasen from comment #3)
> in gnome-system-monitor, you can see the "X memory" column grow rapidly up to
> several gig

I assume you are using the latest+greatest GTK+? This sounds a lot like https://git.gnome.org/browse/polari/commit/?id=a6d7dc2319f82d74 ...
Comment 6 Hussam Al-Tayeb 2015-07-22 10:48:50 UTC
Created attachment 307899 [details]
Valgrind log

(In reply to Dominique Leuenberger from comment #2)
> In git master, at least the leak while switching rooms is gone (likely due
> to the changes with not populating/creating the user list widgets and user
> details).

That's still in polari 3.17.3 and it makes running Polari very difficult since it is pointless to restart polari every 10 times.

I attached valgrind output. I only opened polari for a few seconds and switched a few times between channels and closed it.
Comment 7 Florian Müllner 2015-07-30 01:26:33 UTC
Created attachment 308429 [details] [review]
chatView: Always dispose cairo context

Cairo contexts don't play well with SpiderMonkey's GC, and thus need to
be disposed explicitly. However we are currently not doing that when
returning early from ::draw, piling up resources in turn.
Comment 8 Hussam Al-Tayeb 2015-07-30 06:13:24 UTC
Amazing. That stopped the memory increase in Polari!

Offtopic question By the way, is it possible that the leaks in gnome-mines are due to cairo as well? It leaks more memory every time is draws a new board (new game).
Comment 9 Hussam Al-Tayeb 2015-07-30 06:19:51 UTC
Ok, while this patch stops the memory increase when switching between channels, there is another memory leak when viewing the user list in active channels multiple times.

To reproduce, go to irc.freenode.org and to heavy channels such as #systemd and another channel.
1) Click the user list in #systemd. Memory goes up.
2) Switch to another channel and view the user list. Memory goes.

3) Go back to #systemd and view the user list again. Memory goes up again. (that's twice for the #systemd channel user list)
Comment 10 Florian Müllner 2015-07-30 10:16:22 UTC
Comment on attachment 308429 [details] [review]
chatView: Always dispose cairo context

Attachment 308429 [details] pushed as 96e41c0 - chatView: Always dispose cairo context

Keeping open for the user list issue mentioned in the last comment.
Comment 11 Hussam Al-Tayeb 2015-07-31 20:06:36 UTC
The lag when switching channels seems to be related to user list size as well.
Try switching between #systemd, #kde, and #wordpress on irc.freenode.org.
It causes CPU spikes :)
Comment 12 Hussam Al-Tayeb 2015-08-01 19:50:03 UTC
I think what I am observing is the following:
1) open #systemd and view the user list. The list is loaded in memory.
2) switch to another channel and view the user list. the list is also loaded in memory.
3) wait a bit till the user list possibly changed on #system before going back to systemd.
4) go back to #systemd and view the user list again. The new user list is loaded and polari eats more memory. 

It likely loaded a new #systemd user list without freeing old #systemd user list from memory :(
Comment 13 Florian Müllner 2015-08-01 20:21:37 UTC
(In reply to Hussam Al-Tayeb from comment #12)
> It likely loaded a new #systemd user list without freeing old #systemd user
> list from memory :(

I don't see how this would happen, as we gtk_widget_destroy() the user list on each channel change.
Comment 14 Hussam Al-Tayeb 2015-08-01 20:52:38 UTC
Ah ok, thank you.
It must be something else then.
Comment 15 Kunaal Jain 2016-02-18 13:33:07 UTC
(In reply to Hussam Al-Tayeb from comment #12)
> I think what I am observing is the following:
> 1) open #systemd and view the user list. The list is loaded in memory.
> 2) switch to another channel and view the user list. the list is also loaded
> in memory.
> 3) wait a bit till the user list possibly changed on #system before going
> back to systemd.
> 4) go back to #systemd and view the user list again. The new user list is
> loaded and polari eats more memory. 
> 
I can confirm, this causes memory leak for me too in the master branch
Comment 16 André Klapper 2021-06-10 11:05:59 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Polari, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/polari/-/issues/

Thank you for your understanding and your help.