Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[GTK] Fix several memory leaks in the GTK backend #4112
Description of Change
This serie of patches fixes several memory leaks in the GTK backend.
Another issue is how disposal of Gtk objects is handled, wich is now incorrectly done using the Dispose function. Gtk objects should be disposed using the Destroy function that will automatically iterate over the children and destroy them too (https://developer.gnome.org/gtk2/stable/GtkWidget.html#gtk-widget-destroy).
The gtk-sharp bindings discourage the use of Dispose and don't even call the base class, leaving it without effect (https://github.com/mono/gtk-sharp/blob/gtk-sharp-2-12-branch/gtk/Object.custom#L98), so that's why Gtk objects should override the Destroy function. Problably the gtk-sharp bindings should be changed at some point to have a more idiomatic pattern for disposal, but that would break backwards compatibility, so right now the only possible solution is to use Destroy.
I created a demo application with a MaterDetail that calls the GC on each Detail change. As you can see the number of live objects in master keeps growing while in this branch it's mostly steady going up and down.
Create a sample MasterDetail application with 2 pages and some content inside the pages.
Regarding the MasterDetailPage leak, I am not so sure if the solution is the correct one. Should the MasterDetailPage be responsible of disposing the old Detail or should the application be responsible of doing so? I am think of scenarios in which the application would want to reuse the Page and just switch them using the Detail property.
I will check that because I thought I fixed all of them. There are two different scenarios, Controls using Gtk elements directly, where you have to use Destroy, and those inheriting from ViewRenderer where the base class handles it and you can have a more idiomatic implementation using Dispose
@ylatuya can you rebase this to master? There were some errors that got checked into master a while ago and your branch doesn't have the fix so the build is currently failing with