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 766322 - GtkSourceBuffer is occasionally leaked
GtkSourceBuffer is occasionally leaked
Status: RESOLVED INCOMPLETE
Product: gtksourceview
Classification: Platform
Component: File loading and saving
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GTK Sourceview maintainers
GTK Sourceview maintainers
Depends on:
Blocks:
 
 
Reported: 2016-05-12 12:33 UTC by Christian Hergert
Modified: 2016-06-25 20:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Hergert 2016-05-12 12:33:20 UTC
I've noticed this in both Builder and confirmed in Gedit as well, that sometimes (not always) the GtkSourceBuffer (IdeBuffer, GeditDocument) are leaked.

I can trigger it in both Builder and Gedit by opening a document, and then closing it after a couple seconds. It doesn't always happen, but I'd say about half the times it does.

I *think* it has something to do with the loading process (GtkSourceFile, GtkSourceBufferOutputStream, GtkSourceFileLoader), but all I have as evidence is my debugging process I've been going through.

I also see leaks of GtkSourceFile, GtkSourceContextEngine, etc, but I'm relatively sure those are a side-effect of the buffer being leaked.

I'm looking into this, but would love some pointers or anyone else to join along in the hunt.
Comment 1 Christian Hergert 2016-05-12 13:03:55 UTC
I noticed I can trigger this with "empty" files too, so perhaps not related to loading.
Comment 2 Sébastien Wilmet 2016-05-14 11:41:27 UTC
How do you test that the GObject is leaked? With gobject-list?
https://git.collabora.com/cgit/user/danni/gobject-list.git/

From what I tested several releases ago, in gedit the GtkSourceBuffer is correctly finalized. But the RAM usage doesn't decrease. Load e.g. a 10MB file in gedit, close it, and the RAM usage remains the same. Then re-load the file, and the RAM usage doesn't increase, although it is a different GtkSourceBuffer.

I didn't investigate further, but it's maybe the same problem as:
https://blogs.gnome.org/alexl/2009/02/17/eternal-vigilance/
Comment 3 Christian Hergert 2016-05-14 12:21:53 UTC
Not a fragmentation or gslice issue. I also tested with G_SLICE=always-malloc.

Use a gobject debug build, set GOBJECT_DEBUG=instance-count and then search for geditdocument in the statistics tab. You'll also need to hit the record button in the top left so that you see updates. Then close the document in gedit.

I almost always see the first document leaked.

I did some g_object_run_dispose() cleanup in IdeBufferManager that seems to help things, but I need to dig deeper later to see what the cause was. I actually see this less in Builder now than I do in Gedit, so its possible that both gedit/builder just had bugs with similar symptoms. Could be related to Gtk templates if the first document is created there, but that is just a wild guess based on no information.

If I get my other todo's done for the day, ill take another look.
Comment 4 Sébastien Wilmet 2016-06-12 11:05:16 UTC
So does the problem come from GtkSourceView or the application?
Comment 5 Christian Hergert 2016-06-12 16:09:32 UTC
It's not clear to me, because I've seen it with both Gedit and Builder. However, the dispose hooks we put in place in Builder seem to be working well (although I need to follow up again and double check).
Comment 6 Sébastien Wilmet 2016-06-25 20:52:09 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!