Re: [glib] malloc and bdwgc

[张海 <dreaming in code zh gmail com>]

Thank you very much for pointing me to __libc_* aliases.

However as I was trying to use bdwgc, I didn't figure out whether
bdwgc will infinite loop as I failed to identify the call to memory
allocation in its source :(

bdwgc itself has a --enable-redirect-malloc configure option, and by
greping the source with REDIRECT_MALLOC, I found that to correctly
redefine malloc and free one need to interfere with redefining dlopen,
threads and etc, and it seems quite hard to incorporate those lines of
code into my program. In this case I will need to end up building a
custom bdwgc with --enable-redirect-malloc.

So as I'm building custom libraries, I would prefer rebuilding glib
with patches instead so that I can also --enable-gc-friendly and
--disable-mem-pool.

What do you think of this approach?

And as I dig into glib source, I found that g_slice.c makes reference
to memalign and posix_memalign. for which bdwgc has two GC_* version
but says it lacks testing. Do you know anything I should be careful
about g_slice?

Thomas Martitz <kugel rockbox org>于2016年1月8日周五 下午4:13写道：
> Am 07.01.2016 um 12:26 schrieb 张海:
> > Yes, but glib is the only one I'm using now.
> >
> > Still I don't know how to make GC_malloc() call the original malloc()
> > if I'm using LD_PRELOAD or the wrapper function and dlsym way.
> >
> > Just now I found I've misread
> > http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html
> > , and that such replacement can possibly be done in a single-threaded
> > environment, because the hook is done with a global function pointer
> > variable initialization and it seems that the function is called
> > before memory allocation initialization
> >
> > However as in http://stackoverflow.com/questions/4184280/are-the-gcc-memory-hooks-sometimes-bypassed
> > , there are nasty race conditions for such hook. And my program needs
> > threads.
> >
> > Are there any other way around?
>
> You can simply implement malloc() and friends in your application, then
> the linker shouldn't resolve calls to the libc implementation. If you
> need to call the original malloc() from that you can use secondary names
> / aliases (__libc_malloc() etc). If the latter does not work for your C
> library then you can alternatively access them by dlopen(RTLD_NEXT,
> "malloc");
>
> That said, the above is probably only portable on Unix systems. It
> should be race free as well.
>
> Best regards
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list