Memory leak when return char* from DLL
-
If the application is being build with the runtime libary (CRT) as a DLL (Recommended by Microsoft), then it should be possible to delete memory in the application that have been allocated by the DLL.
Correct. Based on the original question and replies, it was my impression that different heaps/CRTs are being used (see static linkage post), that's why I suggested this way. Of course, using only one CRT will solve the problem, too.
Too many passwords to remember? Try KeePass Password Safe!
-
Correct. Based on the original question and replies, it was my impression that different heaps/CRTs are being used (see static linkage post), that's why I suggested this way. Of course, using only one CRT will solve the problem, too.
Too many passwords to remember? Try KeePass Password Safe!
I m unable to use CRT can u give some kind of code
-
Correct. Based on the original question and replies, it was my impression that different heaps/CRTs are being used (see static linkage post), that's why I suggested this way. Of course, using only one CRT will solve the problem, too.
Too many passwords to remember? Try KeePass Password Safe!
Thank you for confirming this. I'm in a situation myself where I'm considering to convert static-libraries into DLL's to improve linker times. The entire application is already using runtime library as DLL, so the conversion should be a matter of exporting all needed classes in the static libraries.
-
I m unable to use CRT can u give some kind of code
Just follow what Dominik Reichl said in the first comment about ensuring that memory allocated in the DLL is released by the DLL again. Return the char-pointer to the DLL and let the DLL release it again.
-
Just follow what Dominik Reichl said in the first comment about ensuring that memory allocated in the DLL is released by the DLL again. Return the char-pointer to the DLL and let the DLL release it again.
return data char* is locally defined in DLL. so how can release memory of that variable after returning char* variable
-
return data char* is locally defined in DLL. so how can release memory of that variable after returning char* variable
When returning the char* then you take a copy of the char*, but they both point to the same memory in the heap of the DLL. Just pass the copy of the char* from the application to the DLL again, and let the DLL release the memory in its heap. You might consider returning a CString instead of a char*, and ensure that when the CString moves from DLL boundary to the Application boundary that a copy is made of the CString.
-
i m using New and Delete in calling application(MFC). but "delete []cData;" line have error runtime. if we use cData='\0' and after this "delete []cData;" then memory leak still continue.
shivanandgupta wrote:
if we use cData='\0' and after this "delete []cData;" then memory leak still continue.
Well, if you set cData to '\0' you are manipulating the pointer, not the data it contains. cData is set to null, and that is what you try to delete (and it always succeeds.) Doesn't the DLL supply an API for freeing this string? IMHO dll's should always be designed that way.
-
When returning the char* then you take a copy of the char*, but they both point to the same memory in the heap of the DLL. Just pass the copy of the char* from the application to the DLL again, and let the DLL release the memory in its heap. You might consider returning a CString instead of a char*, and ensure that when the CString moves from DLL boundary to the Application boundary that a copy is made of the CString.
I have try but it is not working. return char* is defined in dll's function as a local variable. it will work well when we defined static variable. but i don't want to create static variable in my DLL.
-
shivanandgupta wrote:
if we use cData='\0' and after this "delete []cData;" then memory leak still continue.
Well, if you set cData to '\0' you are manipulating the pointer, not the data it contains. cData is set to null, and that is what you try to delete (and it always succeeds.) Doesn't the DLL supply an API for freeing this string? IMHO dll's should always be designed that way.
if we use delete without using '\0' then problem occur about heap at run time.
-
if we use delete without using '\0' then problem occur about heap at run time.