On Wed, May 19, 2021 at 10:30:30PM +0200, Olaf Hering wrote: > Currently src/libxl/ allocates a bunch of buffers with variants of g_new0() > or g_strdup(), which will be consumed by libxenlight.so. Once the objects > which contain these buffers are not needed anymore, libxenlight.so will > release them with ordinary calls to free() in its *_dispose() API. In other > words: libxenlight.so does not use glib. > > While the g_malloc docs of today's glib state that (apparently) the mistake > of using a private allocator was recognized and corrected in glib 2.46, the > same mistake might occur again in the future.
GLib used to have APIs that let you inject a custom malloc impl. They deprecated and then removed the impl for this, and hardcoded GLib to always use the system malloc. IIUC the main reason for this was the increasing use of __constructor__ functions in libraries. It is not practical to have something in main() which configures a replacement malloc impl, because by that point many GLib functions will have already been called using the system malloc. IOW, if you want to replace the system malloc you need to do it process-wide by explicitly linking to a library that overrides the standard C library malloc() APIs. When libvirt adopted glib, I confirmed the long term plans with GLib maintainers and got them to add a docs note to make this explicit: "Since GLib 2.46 g_malloc() is hardcoded to always use the system malloc implementation." https://developer.gnome.org/glib/2.64/glib-Memory-Allocation.html So, there's no need to worry about free/g_free, they are guaranteed identical. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
