On Fri, Jun 26, 2015 at 8:50 PM, Jasper St. Pierre <jstpie...@mecheye.net> wrote:
> Yeah, we've all been sort of aware of this for some time. I've abused > it to the fact where I know that malloc and g_new / free and g_free > will *always* be the same since a specific glib version. > > I think removing all the code is fine. > > On Fri, Jun 26, 2015 at 8:38 PM, Alexander Larsson <al...@redhat.com> > wrote: > > So, I just tried to use the memory profiler in glib, and I crashes > > really early because the gobject constructor (gobject_init_ctor) calls > > g_malloc before main() is reached. > > > > This means g_mem_set_vtable() is impossible to use. I don't necessarily > > think this is all that bad. Honestly we should never have made it a > > vtable (one extra vfunc per malloc...) and instead do memory profiling > > etc the "normal" way, i.e. LD_PRELOAD something with malloc > > interceptors. Maybe we should just remove all this code and keep > > g_mem_set_vtable as a dummy function that prints a deprecation warning? > Would it be possible to write a how-to page on the Gnome wiki that the documentation of the now-deprecated function would point to? I'm afraid that new developers would be the ones hit hardest by this. I certainly used g_mem_set_vtable to my benefit when I was first starting out with the Gnome stack. I could now figure out how to do memory profiling the "normal" way, as you say, on my own, but I certainly wouldn't have been able to 8 years ago. Regards, -- Philip
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list