gioutil.ListModel memory leak #154
Comments
|
this sounded like a quick fix 😂 ... |
|
Sorry, I think I just completely forgot about this issue until now @.@ The bug isn't being clear to me at all. Just |
|
Branch debug-listmodel (commit babdedb) contains more debug logging to figure this out. It would be wonderful if you could provide the logs for your application on this commit. Running your app with |
Using
Stupid question: where is the log output supposed to be? Stdout doesn't print anything, neither does |
It should be using |
|
When using |
package main
import (
"os"
"time"
"github.com/diamondburned/gotk4/pkg/core/gioutil"
"github.com/diamondburned/gotk4/pkg/gio/v2"
"github.com/diamondburned/gotk4/pkg/glib/v2"
"github.com/diamondburned/gotk4/pkg/gtk/v4"
coreglib "github.com/diamondburned/gotk4/pkg/core/glib"
)
type Item struct {
Value string
}
func main() {
app := gtk.NewApplication("com.github.diamondburned.gotk4-examples.gtk4.simple", gio.ApplicationFlagsNone)
app.ConnectActivate(func() { activate(app) })
if code := app.Run(os.Args); code > 0 {
os.Exit(code)
}
}
var items = gioutil.NewListModel[Item]()
func activate(app *gtk.Application) {
window := gtk.NewApplicationWindow(app)
window.SetTitle("gotk4 Example")
selection := gtk.NewSingleSelection(items)
factory := gtk.NewSignalListItemFactory()
list := gtk.NewListView(selection, &factory.ListItemFactory)
go func() {
for {
time.Sleep(time.Millisecond * 10)
n := []Item{
{Value: "Hello"},
{Value: "World"},
{Value: "Foo"},
{Value: "Bar"},
}
glib.IdleAdd(func() {
items.Splice(0, int(items.NItems()), n...)
})
}
}()
factory.ConnectSetup(func(object *coreglib.Object) {
item := object.Cast().(*gtk.ListItem)
box := gtk.NewBox(gtk.OrientationVertical, 0)
item.SetChild(box)
})
factory.ConnectBind(func(object *coreglib.Object) {
item := object.Cast().(*gtk.ListItem)
valObj := items.Item(item.Position())
val := gioutil.ObjectValue[Item](valObj)
child := item.Child()
box, _ := child.(*gtk.Box)
label := gtk.NewLabel(val.Value)
box.Append(label)
})
window.SetChild(list)
window.SetDefaultSize(400, 300)
window.Show()
}That's a minimal example. Running this will increase memory usage over time. |
|
I think there's actually 2 leaks here:
|
|
I believe package main
import (
"log/slog"
"os"
"github.com/diamondburned/gotk4/pkg/core/gioutil"
"github.com/diamondburned/gotk4/pkg/gio/v2"
"github.com/diamondburned/gotk4/pkg/glib/v2"
"github.com/diamondburned/gotk4/pkg/gtk/v4"
)
func init() {
slog.SetDefault(slog.New(slog.NewTextHandler(os.Stderr, &slog.HandlerOptions{
Level: slog.LevelDebug,
})))
}
type Item struct {
Value string
}
func main() {
app := gtk.NewApplication("com.github.diamondburned.gotk4-examples.gtk4.simple", gio.ApplicationFlagsNone)
app.ConnectActivate(func() { activate(app) })
if code := app.Run(os.Args); code > 0 {
os.Exit(code)
}
}
var items = gioutil.NewListModel[Item]()
func activate(app *gtk.Application) {
factory := gtk.NewSignalListItemFactory()
// factory.ConnectBind(func(object *coreglib.Object) {
// listItem := object.Cast().(*gtk.ListItem)
// ourItem := gioutil.ObjectValue[Item](items.Item(listItem.Position()))
// slog.Debug("Binding", "item", ourItem)
// })
selection := gtk.NewSingleSelection(items)
list := gtk.NewListView(selection, &factory.ListItemFactory)
window := gtk.NewApplicationWindow(app)
window.SetTitle("gotk4 Example")
window.SetChild(list)
window.SetDefaultSize(400, 300)
window.Show()
n := []Item{
{Value: "Hello"},
{Value: "World"},
{Value: "Foo"},
{Value: "Bar"},
}
glib.IdleAdd(func() {
for i := 0; i < 100; i++ {
slog.Debug("Splicing", "n", n)
items.Splice(0, int(items.NItems()), n...)
}
})
}With the Connect call commented out, the items are actually finalized: These log messages aren't seen when the Connect call is used. |
|
Oh! Indeed! I had to fully comment out the whole ConnectSetup call and not just it's body. Leak gone. |
|
This is probably the same old gotk4 reference memory leak that's been happening elsewhere as well. It seems like my original comment was wrong. |
|
This logging suggests that too: In this code, I'm calling |
|
I reckon once I (have enough time to actually) fix the main memory leak issue, this bug will magically fix itself as well. |
diamondburned
added a commit
that referenced
this issue
Nov 3, 2024
Also add g_debug logging to listmodel.c for #154
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
see #126 (comment)
Apparently
ListModelleaks memory.The text was updated successfully, but these errors were encountered: