4 ms·
Yes, it's a nightmare, particularly on OS X with its funny loader semantics that make replacing malloc and free correctly very painful. For example, you can eas
by boulos 11y ago
Yes, it's a nightmare, particularly on OS X with its funny loader semantics that make replacing malloc and free correctly very painful. For example, you can easily LD_PRELOAD your way out of malloc() but did you remember that asprintf also calls an allocation routine and won't use your new malloc? Enjoy.
- ktRolster 11y agoFor debugging purposes, it can sometimes be easier to include a header file "mem_debug.h" or whatever, and redefine malloc: >#define malloc(a) debug_malloc(a, __FILE__, __LINE__) >#define free(a) debug_free(a, __FILE__, __LINE__) >. >. >. Then in your debug_malloc() function you can track where every allocation took place. Not always applicable but nice when it works.
- comex 11y agoHmm, why won't it? Maybe in the past when asprintf and malloc were located in the same dylib, since OS X dylibs generate direct calls to other public functions in the same image (rather than going through the PLT as GNU does by default), but for many years /usr/lib/libSystem.B.dylib has been split into several reexported libraries in /usr/lib/system, so there shouldn't be an issue there. Probably better to use this technique though (should still work in the latest version but needs mprotect): http://eatmyrandom.blogspot.com/2010/03/mallocfree-interception-on-mac-os-x.html http://eatmyrandom.blogspot.com/2010/03/mallocfree-intercept...
- astrange 11y agomalloc is set up to be specifically overridable so that guardmalloc(3)* will work. Are you saying asprintf doesn't work with guardmalloc? * check it out, I used a man reference, am I a professional UNIX developer yet?