Re: MDAC memory leak
On May 9, 9:31 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
When allocations are done, particularly from libraries, there always arise=
s the issue of
when the storage should be freed. Most libraries place the decision of =
when to free
storage on the caller. So if you comment out a call to a library, and s=
torage leaks go
down, you need to investigate under what circumstances the storage is free=
d. It could
well be that you are failing to notify the library that you are finished w=
ith the last set
of data before initiating a call to obtain new data. Since I don't know=
what libraries
you are using, I can't offer advice, but in libraries I've written, and th=
ird-party
libraries I've used, there is typically a requirement to either delete the=
objects
returned or to call the library to delete the objects returned.
strcore leaks are hard to diagnose, because they mean you have an unfreed =
CString. This
is actually fairly rare in most cases, and what you most often see is a CS=
tring as a
member of some class leaking because the instance of the object is still h=
anging around.
There's a capability of breaking on a particular memory allocation, so if =
the effect is
reproducible in that sequences of dumps always give you a leak for allocat=
ion {1024} then
you set the memory allocator breakpoint value to 1024, and you will see wh=
ere it is
called. You will probably find a CString inside a CSomething that is a =
member of an array
or list of a CWhatever, and the real problem is not that you are leaking a=
string, but
that you neglected to free the CWhatever object when you were done with it=
.. I tend to
leave strcore.cpp leaks as the very, very, very last leaks I will ever loo=
k for. When
I've fixed the other leaks (and it is usually a systematic pattern; on the=
first test, I
leak 500 objects, on the second test I leak 3, because I fixed the bug). =
The new smart
pointers also reduce memory leakage by making it impossible to leave dangl=
ing objects
around.
Oh, yes, the other cause is that you DID delete the CWhatever, but the CWh=
atever had a
CSomething* member, and you didn't delete the CSomething* in the ~CWhateve=
r destructor.
That's usually where I go awry, and it is usually a stupid oversight on my=
part (I MEANT
to put the delete in, but got distracted in some way and forgot about it..=
..)
So first look for major leaks, and worry about strcore leaks as the very, =
very last thing,
and you may not have to deal with them at all.
It helps if you take a look at the line that says
#define new DEBUG_NEW
or whatever it is (including its #if... conditionals) and make sure all yo=
ur modules have
it. This sometimes helps, because it forces the debug allocator call to=
be issued, which
includes the file/line information in the object.
=
joe
On Fri, 9 May 2008 14:36:00 -0700, Prashant <Prash...@discussions.microsof=
t.com> wrote:
Joseph,
Thanks for you reply. Actually when we commented all the calls related to=
the database the memory usage as well as the amount of leak came down
subsequently.
Also when we used some of the memory leak tools suggested on microsoft si=
te
those are showing leak in strcore.cpp.
Thanks,
Prashant
"Joseph M. Newcomer" wrote:
See below...
On Wed, 7 May 2008 02:11:00 -0700, App shows memory leak on some machin=
es.
<Appshowsmemoryleakonsomemachi...@discussions.microsoft.com> wrote:
Actually I've originally used AfxBeginThread() function to launch thre=
ad and
just a return statement while exiting thread. And since I was getting =
handle
leak along with memory leak, I tried using CloseHandle() in the previo=
usly
mentioned way. After this change I found no difference in app's behavi=
or.
I again revert back to original code where I've used a return statemen=
t in
the top level thread function. Still I can find same behavior (handle =
+
memory leak).
I'll like to add some more points here-
-I am launching only one thread from main thread.
Lets say ThreadFirst is launched by main thread. Now, all other thread=
s are
getting launched by ThreadFirst.
It's required since main thread needs to do other task.
-Again there is a critical section (semaphore) in thread function. Man=
y
threads are keep on hanging at the start of critical section waiting f=
or
others threads to leave.
****
I suspect you are confused. A CRITICAL_SECTION is a very efficient l=
ow-level
synchronization primitive. A mutex is a considerably less efficient =
synchronization
primitive. A semaphore is something completely different, and fulfil=
ls the purposes of a
semaphore (a counted exclusion object) and has little to do with mutual=
exclusion of
multiple threads. So when you say "critical section (semaphore)" I b=
ecome suspicious,
because semaphores would not be appropriate here.
And yes, if you have a synchronization object, and you have high conten=
tion, you are
likely to have a lot of threads hanging.
Some rules:
Don't use synchronization. Design your code so there =
is no need for
concurrent access
Lock data, not code
Lock the smallest possible amount of data for the shorte=
st possible time
In the absence of any code example showing the locking, it is hard to g=
uess what you might
have done, but the most likely cause is that you have violated one or m=
ore of the above
rules.
Locking is done when threads rub together. That means there is frict=
ion. And just like
in mechanical systems, friction generates heat and wastes energy. I =
tend to view
synchronization as something that should be avoided by making sure thre=
ads are not
actually rubbing. See my essay "The Best Synchronization is No Synch=
ronization" on my MVP
Tips site. Every once in a while, you need concurrent access, but th=
e more I work with
threads, the less I do it.
joe
****
Can it create any problem??
Thanks,
Digvijay
"Nick Schultz" wrote:
Use Process Explorer fromwww.sysinternals.com. It is free and is =
MUCH
better than Task Manager, you can double click on a process and get =
very
detailed information, including a list of threads and memory usage. =
It also
shows processes in a tree format rather than just a flat list...over=
all its
a better tool.
Go to the Options menu and select "Replace Task Manager" and Process=
Explorer will pop up whenever you press CTRL+ALT+DEL.
Nick
"App shows memory leak on some machines."
<Appshowsmemoryleakonsomemachi...@discussions.microsoft.com> wrote i=
n
messagenews:91870733-F651-4E90-A5E7-88CB6170E89D@microsoft.com...
Thank you Joseph for your reply.
I've used AfxBeginThread() function to launch thread and subsequen=
tly
AfxEndThread() to end it.
I tried using CloseHandle() and checked its return value, also che=
cked
return value for GetLastError(), to make sure that handle is getti=
ng
closed.
Return values were as expected. But, it made no difference in beha=
viour of
exe.
This part of code looks like
//--------------------------------
CWinThread* ThPtr = AfxBeginThread(..);
bool b = ::CloseHandle(ThPtr->m_hThread);
int n = GetLastError();
thread function:
ThreadFunc()
{
.
.
.
AfxEndThread();
returb bRet;
}
//--------------------------------
I've used socket and DB calls inside thread function. For DB
communication,
I've used 'msado15.dll'.
I'll like to know, in which cases application will behave differen=
tly (in
terms of memory leaks) on different machine?
Thanks,
Digvijay
"Joseph M. Newcomer" wrote:
It is FAR more likely that what happened is that you are failing =
to close
the thread
handle of the thread, resulting in a leakage of thread stacks. =
Are you
certain every
thread handle is being closed?
The task manager may suggest that memory usage is increasing (it =
is one
of the few valid
reports about memory it is actually capable of), but you need to =
rule out
lots of other
explanations before pointing to MDAC (not that it might not be th=
e cause,
but the most
common error I've found in multithreaded leaks is stack leakage).=
I
would suggest
downloading the free App Verifier from the Microsoft site and tur=
ning on
all memory
management options.
joe
On Fri, 2 May 2008 07:48:02 -0700, Prashant
<Prash...@discussions.microsoft.com> wrote:
The application is a multithreaded exe involving socket communic=
ation.
The
memory usage in task manager increases when exe is running. It n=
ever
comes
down. In other words, for each thread it increases and never =
comes down
even
after that thread dies.
Thanks,
Digvijay
"Joseph M. Newcomer" wrote:
How do you detect that there is a memory leak? You assert t=
his is
happening without
explaining why you think it is so.
joe
On Thu, 1 May 2008 05:11:01 -0700, App shows memory leak on so=
me
machines. <App shows
memory leak on some machin...@discussions.microsoft.com> wrote=
:
Hi,
My application (developed in VC++) is running fine on most of=
the
machines(without any memory leak). But, it is showing memory =
leaks on
production machine. Even on development side it is showing me=
mory
leaks on
few machine. Why it is so?
...
read more =BB- Hide quoted text -
- Show quoted text -
Just for the information; In MDAC 2.82.3939 which comes with the
Microsoft Windows SP 2 all the memory leaks are fixed? The tools we
downloaded from microsoft site are still showing us leak in msado. So
we wanted to confirm this.
Thanks,
Prashant