You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 13, 2019. It is now read-only.
It is currently possible to create (*glib.Object).Connect closures which close over gotk3 objects, or include them as part of the userdata. This results in the glib package creating a closure context with (reflected) references to the object and saving it globally in a map of GClosures to closure contexts.
Closure contexts are never removed from glib's global map until the GLib runtime frees (when ref count drops to 0) the object the closure is connected to and finalizes the closure. However, these closure contexts still hold references to gotk3 objects, and because they are still technically accessable through the glib closure context map, the Go garbage collecter is unable to know that the objects are no longer live. This results in the gotk3 object, the Go closure, the closure context, and the GClosure never being freed.
The following code snippet demonstrates the problem:
{
b, err:=gtk.ButtonNew()
iferr!=nil {
// badness
}
runtime.SetFinalizer(b, func(_*gtk.Button) {
fmt.Println("finalizing button")
})
b.Connect("clicked", func() {
_=b// This introduces the circular reference
})
} // b is out of scope, and was never added to another containerruntime.GC() // b's finalizer does not run
The text was updated successfully, but these errors were encountered:
jrick
added a commit
to jrick/xombrero2
that referenced
this issue
Apr 25, 2014
This change manually removes the connected signal by their id for
gotk3 and go-webkit2 objects for HTML pages when a tab is closed.
This prevents a leak where connected signals can prevent finalizers
from running (see conformal/gotk3#55).
Also, rather than waiting for the glib.Object finalizer on each
wk2.WebView (which may take up to 3 minutes before the Go GC runs),
explicitly .Destroy() the webview widget. This causes the
WebKitWebProcess to be immediately closed.
jrick
changed the title
Closure memory leaks
Connect closure memory leaks
Jun 23, 2014
It is currently possible to create (*glib.Object).Connect closures which close over gotk3 objects, or include them as part of the userdata. This results in the glib package creating a closure context with (reflected) references to the object and saving it globally in a map of GClosures to closure contexts.
Closure contexts are never removed from glib's global map until the GLib runtime frees (when ref count drops to 0) the object the closure is connected to and finalizes the closure. However, these closure contexts still hold references to gotk3 objects, and because they are still technically accessable through the glib closure context map, the Go garbage collecter is unable to know that the objects are no longer live. This results in the gotk3 object, the Go closure, the closure context, and the GClosure never being freed.
The following code snippet demonstrates the problem:
The text was updated successfully, but these errors were encountered: