If I'm using Kotlin/Native with GTK, and storing p...

# kotlin-native

[serebit]

If I'm using Kotlin/Native with GTK, and storing pointers to widgets (those pointers being given by gtk_new builder functions) in a Kotlin class, how can I ensure that the pointers are being freed by program exit? If they were being allocated by Kotlin/Native and not GTK, I could use nativeHeap.free, but I'm not sure how to handle it in this case.

[Kris Wong]

all memory is freed on program exit

[serebit]

Not so sure about that:

/home/serebit/Code/wraith-master/gtk/build/bin/linuxX64/debugExecutable/gtk.kexe
Memory leaks detected, 193 objects leaked!
Use `Platform.isMemoryLeakCheckerActive = false` to avoid this check.

[Kris Wong]

when a process dies its memory is reclaimed

[Kris Wong]

that doesn't mean you don't have memory leaks while the program is running

[serebit]

This is still something I'd like to resolve.

[Kris Wong]

are you really asking how do you make sure the memory is released while the program is running?

[serebit]

...Touche.

[Kris Wong]

🙂

[Kris Wong]

is suspect if heap space is allocated natively, then it must also be freed natively. if you pass the ownership to your K/N code, then you probably need native code you can call to deallocate it.

[Kris Wong]

i imagine gtk has functions to deallocate? and you have bindings for gtk in your kotlin module?

[serebit]

It does, and I do. I think I've found a lead though, will update if I figure it out.

[kevin.cianfarini]

piggy backing on this...is there any way to encapsulate manual memory management? The only thing I can think of is to hook into the GC cycle and free memory when an object is getting collected.

This is essentially a finalizer though, which are evil. Has anyone figured out a better way to do this so manual memory management doesn't pollute a whole codebase?

[napperley]

Do you have any stable references that you are forgetting to dispose (will be picked up by the memory leak detector)? Recent Kotlin versions include a memory leak detector (for Kotlin Native only), which I have encountered before when running a GTK based application (through a debug binary). Unfortunately the detector doesn't provide a full report indicating what has gone wrong, and some possible solutions to fix the problems.

[serebit]

I do have stable references that are created for each callback, but I dispose of all of them from within the callbacks