EXE uses a new memory, but the delete operation in the DLL program causes an error.

After adding some results to the class, there was a big problem: An error occurred after the Destructor was called. I finally thought about the problem and searched for it:

The following text references from the http://hi.baidu.com/huhe/blog/item/0b422edd1f1563d98c1029a3.html
Thank you for your analysis.

One module, one heap, one thread, and one stack.
The malloc memory in the DLL will be free in the EXE and an error will occur.

CRT (C Runtime Library) does not use the default heap of the process to implement malloc (calling malloc in new), but uses a Global handle _ crtheap to allocate memory. This _ crtheap is created in xxxcrtstartup (the entry point function provided by CRT.
Because of the static CRT connection, there is also a CRT in the main DLL, so there is also a _ crtheap. In DLL, the new uses the _ crtheap handle in DLL to allocate the heap. In EXE, the delete uses the _ crtheap in EXE to release the heap. Of course, the failure!

Solution:
1. Output a function in the DLL to the EXE call, which is used to release the memory allocated by the DLL;
2. Replace new with globalalloc () and delete with globalfree;
3. Use a single heap, allocate memory using heapalloc (getprocessheap (), 0, size), and release memory using heapfree (getprocessheap (), 0, P );
4. Change the use run-time liberary of the code generation on the C/C ++ tab of DLL and exe settings to debug multithreaded DLL, and change it to multithreaded DLL in the release version; in this way, a CRT is used -- msvcrt. DLL.
 
The following is a discussion on csdn, which is also discussed in detail.
Http://topic.csdn.net/t/20031009/17/2338051.html

The above information is found on the Internet. I did a detailed test today and the results are as follows:

Test 1: use a combination of malloc and free to allocate and release memory. Use malloc in DLL and free in exe.
I have built a Win32 DLL project, and C/C ++-> code generation is set to multithread DLL debug, but the EXE project is set to multithread debug, so no matter what happens, an exception is always thrown. this indirectly proves that the above description is correct. If I modify the EXE project setting to multithread DLL debug, the malloc/free combination can work well.

Test 2: heapalloc/heapfree combination is used to allocate and release the memory, heapalloc is used in DLL, and exe is released.
The configuration of EXE is still multithread debug, heapalloc (getprocessheap (), heap_zero_memory, 1024) allocation in DLL, heapfree (getprocessheap (), 0, P) Release in EXE ,, it still fails to run normally or throws an exception. If the EXE is set to multithread DLL debug, it will run normally.

Test 3: heapalloc/heapfree is used, but the DLL exports a method to release the memory allocated in the DLL.
If the EXE configuration is multithread debug, it cannot run normally and an exception is thrown. If it is modified to multithread DLL, debug runs normally.
 
The conclusion is as follows:
Whether malloc/free combination or heapalloc/heapfree combination is used, the EXE project must be set to multithread DLL debug for normal operation. The discussion on csdn seems to be caused by access here, the DLL settings cannot be modified at will. Therefore, if this problem is involved, the best way is to release the module in which the module is allocated, or else it will lead to more troubles.

From: http://blog.csdn.net/blz_wowar/archive/2008/03/13/2176536.aspx

Expansion: http://www.dewen.org/q/1758/