Re: shared DLL VS static Link, Are they different?
asm23 wrote:
David Lowndes wrote:
program works fine. But When I build the APP with "Using MFC as
shared DLL" option, there are many memory leak report when I exit the
APP.
And if you remove those 2 lines of code, do you still see leaks
reported when you use MFC DLL?
I was confused that why the "break" statement is commented after the
"case DLL_PROCESS_ATTACH:"?
Presumably the writer wanted the thread calling the process attach to
do the same as new threads would. Note that the documentation mentions
"A thread calling the DLL entry-point function with DLL_PROCESS_ATTACH
does not call the DLL entry-point function with DLL_THREAD_ATTACH. "
Further more, the cvCreateImage and cvReleaseImage function in my APP
is regularly simple, they only allocate a piece of memory and
delete it.
And is it that memory that's reported as a leak, or something else
(like MFC global variables)?
Dave
Thank you for your quick reply.
If I remove those 2 lines of code, the APP runs very well and NO memory
leaks reported. ( in Both DLL or static MFC mode )
Further more, I create the Dialog based APP with MFC APP wizard, and it
is so simple that I only add a pointer member IplImage * m_iplImage in
class COpenCVdialogDlg .
The source code of " cxcore001.dll" is build with the option :
"NOT using MFC "
"debug multithread DLL"
Is there something wrong?
asm:
Normally, a DLL is designed to work with the DLL version of the CRT, and the
client application should do this also. This causes the app and the DLL to use a
single heap, so that memory can be allocated in one module and freed in the
other. Normally, also, you should have a debug and release version of the DLL,
which you use in your debug and release build respectively.
Some thoughts:
1. You say the dll is built using *debug* multi-threaded DLL (this is /MDd). Do
you not have a release version also? What happens if you compile your app with
/MDd. Or is this what you are doing?
2. I'm not sure about this, but maybe the DLL is leaking memory (not your
fault), but you only see this memory leak if the DLL is using the same heap as
your application.
3. There is one thing in your code that seems odd to me:
m_iplImage = cvCreateImage(ImgSize,IPL_DEPTH_8U,IMAGE_CHANNELS);
cvReleaseImage(&m_iplImage);
Are you sure the second line shouldn't be
cvReleaseImage(m_iplImage);
?
4. Now it may be that the interface of this DLL is such that it does not require
the client to be using the same heap (the cvReleaseImage() suggests this). In
this case, IMHO, it makes sense to compile both the DLL and the application with
static linking, so as to avoid deployment issues on target machines.
[Personally, I will do almost anything to avoid dynamic linking...]
Apart from the memory leak, what happens if you actually try to use this
library? Does in work with both static and dynamic linking?
Third party DLL's can be a real pain...
--
David Wilkinson
Visual C++ MVP