3
3Nu
Guest
Hi,
Background: I want to replace (by patching) CRT memory allocation functions with my own functions.
So, investigating a little inside the ucrt source code, I figured that, instead of patching malloc/realloc/free etc, I could just patch _malloc_base/_realloc_base/_free_base etc. Doing so, I wouldn't need to patch every single _aligned* variations too as these internally are already calling the *_base version of their plain functions.
The same is "almost" true for the *_dbg version of the functions, but for malloc_dbg/realloc_dbg/calloc_dbg. Ideally, I would like to keep compatibility with these functions, as they implement debug functionalities that are used by third party profilers and I don't want to loose their programmatic features (crtDbg* etc.) either.
Unfortunately, what is preventing me to have a clean patching code, is the use of HeapAlloc inside heap_alloc_dbg_internal() [heap_dbg.cpp] (invoked by malloc_dbg/calloc_dbg) instead of _malloc_base, as, for example, free_dbg does with _free_base. Also, realloc_dbg, ends up calling HeapSize instead of _msize_base. Both _malloc_base and _msize_base ultimately resolve respectively to a HeapAlloc and HeapSize, so it looks to me they could be a viable alternative to the current code paths.
I was wondering if there is anything I am missing that prevents the use of _malloc_base and _msize_base instead of the Heap* functions, but the fact that maybe nobody had this very same needs before? If there is nothing preventing to do so, is this something VS developers can consider for the future releases of the Windows SDK?
Thanks,
Fabio
Continue reading...
Background: I want to replace (by patching) CRT memory allocation functions with my own functions.
So, investigating a little inside the ucrt source code, I figured that, instead of patching malloc/realloc/free etc, I could just patch _malloc_base/_realloc_base/_free_base etc. Doing so, I wouldn't need to patch every single _aligned* variations too as these internally are already calling the *_base version of their plain functions.
The same is "almost" true for the *_dbg version of the functions, but for malloc_dbg/realloc_dbg/calloc_dbg. Ideally, I would like to keep compatibility with these functions, as they implement debug functionalities that are used by third party profilers and I don't want to loose their programmatic features (crtDbg* etc.) either.
Unfortunately, what is preventing me to have a clean patching code, is the use of HeapAlloc inside heap_alloc_dbg_internal() [heap_dbg.cpp] (invoked by malloc_dbg/calloc_dbg) instead of _malloc_base, as, for example, free_dbg does with _free_base. Also, realloc_dbg, ends up calling HeapSize instead of _msize_base. Both _malloc_base and _msize_base ultimately resolve respectively to a HeapAlloc and HeapSize, so it looks to me they could be a viable alternative to the current code paths.
I was wondering if there is anything I am missing that prevents the use of _malloc_base and _msize_base instead of the Heap* functions, but the fact that maybe nobody had this very same needs before? If there is nothing preventing to do so, is this something VS developers can consider for the future releases of the Windows SDK?
Thanks,
Fabio
Continue reading...