Re: MDAC memory leak
Just as infromation. Now after MDAC 2.82.3939 which comes with Windows
2003 SP2 there are no leaks? The tools which we downloaded from
microsoft site still showing leak in msado.
Thanks,
Prashant
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 -