none
heap_alloc_dbg_internal, what about using _malloc_base() instead of HeapAlloc()? RRS feed

  • General discussion

  • 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




    • Edited by 3Nu Thursday, November 14, 2019 1:51 PM
    Thursday, November 14, 2019 12:40 PM

All replies

  • Now That's What I call... a nicely authored forum question.

    Kudos to you Fabio. I hope you get some equally informed responses.

     

    Best regards,
    Pete


    #PEJL
    Got any nice code? If you invest time in coding an elegant, novel or impressive answer on MSDN forums, why not copy it over to TechNet Wiki, for future generations to benefit from! You'll never get archived again, and you could win weekly awards!

    Have you got what it takes to become this month's TechNet Technical Guru? Join a long list of well known community big hitters, show your knowledge and prowess in your favoured technologies!

    Thursday, November 14, 2019 1:16 PM
    Moderator