Allocation Hooks and C Run-Time Memory Allocations
This topic applies to:
Edition |
Visual Basic |
C# |
F# |
C++ |
Web Developer |
|---|---|---|---|---|---|
Express |
.gif "Topic does not apply") |
|
|
Native only |
|
Pro, Premium, and Ultimate |
|
|
|
Native only |
|
A very important restriction on allocation hook functions is that they must explicitly ignore _CRT_BLOCK blocks (the memory allocations made internally by C run-time library functions) if they make any calls to C run-time library functions that allocate internal memory. The _CRT_BLOCK blocks can be ignored by including code such as the following at the beginning of your allocation hook function:
if ( nBlockUse == _CRT_BLOCK )
return( TRUE );
If your allocation hook does not ignore _CRT_BLOCK blocks, then any C run-time library function called in your hook can trap the program in an endless loop. For example, printf makes an internal allocation. If your hook code calls printf, then the resulting allocation will cause your hook to be called again, which will call printf again, and so on until the stack overflows. If you need to report _CRT_BLOCK allocation operations, one way to circumvent this restriction is to use Windows API functions, rather than C run-time functions, for formatting and output. Because the Windows APIs do not use the C run-time library heap, they will not trap your allocation hook in an endless loop.
If you examine the run-time library source files, you will see that the default allocation hook function, CrtDefaultAllocHook (which simply returns TRUE), is located in a separate file of its own, DBGHOOK.C. If you want your allocation hook to be called even for the allocations made by the run-time startup code that is executed before your application's main function, you can replace this default function with one of your own, instead of using _CrtSetAllocHook.
See Also
Tasks
crt_dbg2 Sample: C Run-Time Debugging Hook Functions