A tricky way of manipulating memory allocation [modified]
-
fifth Edition in Chapter 19, there is one note: Note: It is important to realize that a single address space consists of one executable module and several DLL modules. Some of these modules can link to a static version of the C/ C++ run-time library, some of these modules might link to a DLL version of the C/C++ run-time library, and some of these modules (if not written in C/C++) might not require the C/ C++ run-time library at all. Many developers make a common mistake because they forget that several C/C++ run-time libraries can be present in a single address space. Examine the following code: VOID EXEFunc() { PVOID pv = DLLFunc(); // Access the storage pointed to by pv... // Assumes that pv is in EXE's C/C++ run-time heap free(pv); } PVOID DLLFunc() { // Allocate block from DLL's C/C++ run-time heap return(malloc(100)); } So, what do you think? Does the preceding code work correctly? Is the block allocated by the DLL's function freed by the EXE's function? The answer is: maybe. The code shown does not give you enough information. If both the EXE and the DLL link to the DLL C/C++ run-time library, the code works just fine. However, if one or both of the modules link to the static C/C++ run-time library, the call to free fails. I have seen developers write code similar to this too many times, and it has burned them all. =========================================================================== At first one thing the starup() function do is to initialize a heap used by malloc and free and low-level IO manipulation use in CRT, so when there is two copies CRT liberary in one process adress and there will be two heaps for two groups of malloc and free, and that one block memory grabed by malloc can only be freed by the very free() function in the same copy. but what free() is? in fact free()'s source code is like this: void free(void *ptr) { struct mem_control_block *free; free = ptr - sizeof(struct mem_control_block); free->is_available = 1; return; } every malloc()function return pointer to a block,however there are some bytes ahead the block conserved for system information, and this information is stored in a struct mem_control_block, so indeed the pointer malloc()function returned points to the byte after the mem_control_block. struct mem_control_block { int is_available; //a flag that specify whether this block can be used by any other application i
-
fifth Edition in Chapter 19, there is one note: Note: It is important to realize that a single address space consists of one executable module and several DLL modules. Some of these modules can link to a static version of the C/ C++ run-time library, some of these modules might link to a DLL version of the C/C++ run-time library, and some of these modules (if not written in C/C++) might not require the C/ C++ run-time library at all. Many developers make a common mistake because they forget that several C/C++ run-time libraries can be present in a single address space. Examine the following code: VOID EXEFunc() { PVOID pv = DLLFunc(); // Access the storage pointed to by pv... // Assumes that pv is in EXE's C/C++ run-time heap free(pv); } PVOID DLLFunc() { // Allocate block from DLL's C/C++ run-time heap return(malloc(100)); } So, what do you think? Does the preceding code work correctly? Is the block allocated by the DLL's function freed by the EXE's function? The answer is: maybe. The code shown does not give you enough information. If both the EXE and the DLL link to the DLL C/C++ run-time library, the code works just fine. However, if one or both of the modules link to the static C/C++ run-time library, the call to free fails. I have seen developers write code similar to this too many times, and it has burned them all. =========================================================================== At first one thing the starup() function do is to initialize a heap used by malloc and free and low-level IO manipulation use in CRT, so when there is two copies CRT liberary in one process adress and there will be two heaps for two groups of malloc and free, and that one block memory grabed by malloc can only be freed by the very free() function in the same copy. but what free() is? in fact free()'s source code is like this: void free(void *ptr) { struct mem_control_block *free; free = ptr - sizeof(struct mem_control_block); free->is_available = 1; return; } every malloc()function return pointer to a block,however there are some bytes ahead the block conserved for system information, and this information is stored in a struct mem_control_block, so indeed the pointer malloc()function returned points to the byte after the mem_control_block. struct mem_control_block { int is_available; //a flag that specify whether this block can be used by any other application i
-
fifth Edition in Chapter 19, there is one note: Note: It is important to realize that a single address space consists of one executable module and several DLL modules. Some of these modules can link to a static version of the C/ C++ run-time library, some of these modules might link to a DLL version of the C/C++ run-time library, and some of these modules (if not written in C/C++) might not require the C/ C++ run-time library at all. Many developers make a common mistake because they forget that several C/C++ run-time libraries can be present in a single address space. Examine the following code: VOID EXEFunc() { PVOID pv = DLLFunc(); // Access the storage pointed to by pv... // Assumes that pv is in EXE's C/C++ run-time heap free(pv); } PVOID DLLFunc() { // Allocate block from DLL's C/C++ run-time heap return(malloc(100)); } So, what do you think? Does the preceding code work correctly? Is the block allocated by the DLL's function freed by the EXE's function? The answer is: maybe. The code shown does not give you enough information. If both the EXE and the DLL link to the DLL C/C++ run-time library, the code works just fine. However, if one or both of the modules link to the static C/C++ run-time library, the call to free fails. I have seen developers write code similar to this too many times, and it has burned them all. =========================================================================== At first one thing the starup() function do is to initialize a heap used by malloc and free and low-level IO manipulation use in CRT, so when there is two copies CRT liberary in one process adress and there will be two heaps for two groups of malloc and free, and that one block memory grabed by malloc can only be freed by the very free() function in the same copy. but what free() is? in fact free()'s source code is like this: void free(void *ptr) { struct mem_control_block *free; free = ptr - sizeof(struct mem_control_block); free->is_available = 1; return; } every malloc()function return pointer to a block,however there are some bytes ahead the block conserved for system information, and this information is stored in a struct mem_control_block, so indeed the pointer malloc()function returned points to the byte after the mem_control_block. struct mem_control_block { int is_available; //a flag that specify whether this block can be used by any other application i
-
fifth Edition in Chapter 19, there is one note: Note: It is important to realize that a single address space consists of one executable module and several DLL modules. Some of these modules can link to a static version of the C/ C++ run-time library, some of these modules might link to a DLL version of the C/C++ run-time library, and some of these modules (if not written in C/C++) might not require the C/ C++ run-time library at all. Many developers make a common mistake because they forget that several C/C++ run-time libraries can be present in a single address space. Examine the following code: VOID EXEFunc() { PVOID pv = DLLFunc(); // Access the storage pointed to by pv... // Assumes that pv is in EXE's C/C++ run-time heap free(pv); } PVOID DLLFunc() { // Allocate block from DLL's C/C++ run-time heap return(malloc(100)); } So, what do you think? Does the preceding code work correctly? Is the block allocated by the DLL's function freed by the EXE's function? The answer is: maybe. The code shown does not give you enough information. If both the EXE and the DLL link to the DLL C/C++ run-time library, the code works just fine. However, if one or both of the modules link to the static C/C++ run-time library, the call to free fails. I have seen developers write code similar to this too many times, and it has burned them all. =========================================================================== At first one thing the starup() function do is to initialize a heap used by malloc and free and low-level IO manipulation use in CRT, so when there is two copies CRT liberary in one process adress and there will be two heaps for two groups of malloc and free, and that one block memory grabed by malloc can only be freed by the very free() function in the same copy. but what free() is? in fact free()'s source code is like this: void free(void *ptr) { struct mem_control_block *free; free = ptr - sizeof(struct mem_control_block); free->is_available = 1; return; } every malloc()function return pointer to a block,however there are some bytes ahead the block conserved for system information, and this information is stored in a struct mem_control_block, so indeed the pointer malloc()function returned points to the byte after the mem_control_block. struct mem_control_block { int is_available; //a flag that specify whether this block can be used by any other application i
-
Hey man, thanks a lot, that's what I want. But it is still lacking of more explanation in deep, any way, it's enough. Any more clear in-depth explanation will be appreciated! Jack
-
do you know what "ertain types of objects" are created using CRT heap? and why is a necessary? Further, it seems unecessary to allocate a heap per CRT copy, in stead of let all CRTs use exe. heap, which is what heap meant to be. So if the CRT heap exists, it must have a good reason. The reason lies on the data stored in the heap, what data and why stored there?
-
"d now there matching everything as if the object was created at the local heap" this is odd, then there is no need to allocate a heap for CRT. is all this back-compatible consideration? the original CRT developers use this mechanism for some specific reason that is rarely used today but for compatible's sake Microsoft still maintain this feature?
-
"d now there matching everything as if the object was created at the local heap" this is odd, then there is no need to allocate a heap for CRT. is all this back-compatible consideration? the original CRT developers use this mechanism for some specific reason that is rarely used today but for compatible's sake Microsoft still maintain this feature?
-
"d now there matching everything as if the object was created at the local heap" this is odd, then there is no need to allocate a heap for CRT. is all this back-compatible consideration? the original CRT developers use this mechanism for some specific reason that is rarely used today but for compatible's sake Microsoft still maintain this feature?
-
Gorgeous! The best answer i have ever got since I have started asking for help in the internet! And I spend almost an hour to chew this answer. Thanks a ton! To make sure I've understood what you are saying,are you saying if each dll's referred CRT copy's version are the same, their would be no problem creating an object in this dll and deleting in another because they use the same allocator the same allocating algorithm??
-
Gorgeous! The best answer i have ever got since I have started asking for help in the internet! And I spend almost an hour to chew this answer. Thanks a ton! To make sure I've understood what you are saying,are you saying if each dll's referred CRT copy's version are the same, their would be no problem creating an object in this dll and deleting in another because they use the same allocator the same allocating algorithm??
-
Hehe, I got it. And I'm waiting for the moment I have to allocate-deallocate memory across dll boundries in my job, before that I may be follow the rule: if you get a pointer to newly created memory by a dll, then you have to use a function in this dll and past this pointer as a parameter to it to delete( release indeed) the memory.
-
Hehe, I got it. And I'm waiting for the moment I have to allocate-deallocate memory across dll boundries in my job, before that I may be follow the rule: if you get a pointer to newly created memory by a dll, then you have to use a function in this dll and past this pointer as a parameter to it to delete( release indeed) the memory.
-
I read a lot of arctiles in heap management these days. you can goole "free lists lookaside table filetype:ppt" and there a bunch of useful infomation. I find a serious problem: 1.all mallocs and frees in different versions of CRT of Windows call the same RtlAllocateHeap(), and RtlFreeHeap(), and all infomation needed by RtlAllocateHeap,and AtlFreeHeap() was builded by ntoskrnl.exe. It seems to me that malloc and free don't need to interact with CRT. What specific info is contained in CRT, rather than process management field(PEB or sth.)?
-
I read a lot of arctiles in heap management these days. you can goole "free lists lookaside table filetype:ppt" and there a bunch of useful infomation. I find a serious problem: 1.all mallocs and frees in different versions of CRT of Windows call the same RtlAllocateHeap(), and RtlFreeHeap(), and all infomation needed by RtlAllocateHeap,and AtlFreeHeap() was builded by ntoskrnl.exe. It seems to me that malloc and free don't need to interact with CRT. What specific info is contained in CRT, rather than process management field(PEB or sth.)?
-
"A heap descriptor"? you mean "heap structures"? which contain Freelists, Lookaside Lists and the like and which reside in the front of A heap? Does CRT change the content of heap descriptor directorly or it was edited while inside RltHeapAllocate or RltFreeHeap? It seems to me the latter one is safer and more reasonable. The second question, yes, the debug and release version does contain different info of heap, because debug version want to provide more info such as heap memory leak, heap memory overflows, etc. What's the main differneces between each release versions? I discover one, which you can see in page 32 in XPSP2 Heap Exploitation.ppt( you can find this on internet, or i can send you by email) And I want to make sure that: chances are that when one copy of CRT is mapped to process memory address in DLLMain(), its own heap can be initialized. Can this happens because I saw this opinion in some articles. But you are saying there are only one heap-the default heap for each version of CRT to malloc and free. Are you sure with what you are saying?
-
"A heap descriptor"? you mean "heap structures"? which contain Freelists, Lookaside Lists and the like and which reside in the front of A heap? Does CRT change the content of heap descriptor directorly or it was edited while inside RltHeapAllocate or RltFreeHeap? It seems to me the latter one is safer and more reasonable. The second question, yes, the debug and release version does contain different info of heap, because debug version want to provide more info such as heap memory leak, heap memory overflows, etc. What's the main differneces between each release versions? I discover one, which you can see in page 32 in XPSP2 Heap Exploitation.ppt( you can find this on internet, or i can send you by email) And I want to make sure that: chances are that when one copy of CRT is mapped to process memory address in DLLMain(), its own heap can be initialized. Can this happens because I saw this opinion in some articles. But you are saying there are only one heap-the default heap for each version of CRT to malloc and free. Are you sure with what you are saying?
Shall we talk on MSN? my MSN is dingxiaofenguni@gmail.com