Silently leaked return value of callbacks
Submitted by Xavier Claessens
I've been reading gjs' code for the return value of a callback/vfunc.
With transfer-none it silently leaks strings, filenames and containers. For example when returning a GPtrArray
<GObject>with transfer-none, gjs will allocate a new GPtrArray and leak it. Possible solutions are either to throw an error claiming it's not supported, or free the memory later in an idle callback. The caller could thus have the opportunity to g_strdup() or g_ptr_array_ref() before returning to mainloop if it wants to keep the returned value. Note that if JS GC runs in another thread (does it?) then I see no way to make it safe though.
With transfer-container nothing is leaked but in the case of a GPtrArray or GHashTable the C code could be expecting that the container owns its elements and have a free_func set. That would make it thread-safe. Maybe we need a specific annotation if that's what the C API is expecting?