CString Memory leaks detected
Robert F TR -- RFC1@trpo5.tr.unisys.com
Thursday, August 22, 1996
Environment: Visual C++ 2.2, Windows NT 4.0 beta2
MFC is reporting memory leaks in module strcore.cpp in
CString::AllocBuffer.
I am doing normal CString stuff using local variables. Whats going on
here? No exceptions have occured, so that not it. Is my program really
leaking memory? If so how do I cleanup after an internal CString call to
AllocCopy?
Object dumps following successive runs of the program seem to indicate
that these buffers ARE actually being released (because the address and
size of the memory reported in the object dump is the same over
successive runs of the application.)
This suggests that either MFC is reporting memory leaks and there are
none or MFC / Windows in releasing memory for me.
Niels Ull Jacobsen -- nuj@kruger.dk
Monday, August 26, 1996
At 08:36 22-08-96 EDT, you wrote:
>
>Environment: Visual C++ 2.2, Windows NT 4.0 beta2
>
>MFC is reporting memory leaks in module strcore.cpp in
>CString::AllocBuffer.
>
>I am doing normal CString stuff using local variables. Whats going on =20
>here? No exceptions have occured, so that not it. Is my program really =
=20
>leaking memory? If so how do I cleanup after an internal CString call to=
=20
>AllocCopy?
Without some code, it's hard to tell what's causing the leaks.=20
Have you checked the KB for articles on CString memory leaks?
"Normal CString stuff" is pretty vague, considering what some people thin=
k of as
"Normal". Are you using GetBuffer()? Are you *sure* all destructors get c=
alled?
Are you using templated collections without implementing all the proper h=
elper=20
functions? And so on..
>
>Object dumps following successive runs of the program seem to indicate =
=20
> that these buffers ARE actually being released (because the address and=
=20
>size of the memory reported in the object dump is the same over =20
>successive runs of the application.)
>
>This suggests that either MFC is reporting memory leaks and there are =20
>none or MFC / Windows in releasing memory for me.
Windows NT will release all memory allocated when your program terminates.
So you will only accumulate memeory leaks if your program runs for a long=
time.
>
>
>
Niels Ull Jacobsen, Kr=FCger A/S (nuj@kruger.dk)
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger=20
group and should be taken as legally binding in every respect.=20
Pigs will grow wings and fly.
Manish Chopra -- manish@earthlink.net
Tuesday, August 27, 1996
Use Bounds Checker or Heap Agent. You are certainly doing something
related to memory overruns or some other part of your program loop is
causing memory leaks which CString doesnt like and your program gives an
exception at CString even if you are playing with it well, which is
weird.
You have to realize NT is a very strict type-checking OS.
Niels Ull Jacobsen wrote:
>=20
> At 08:36 22-08-96 EDT, you wrote:
> >
> >Environment: Visual C++ 2.2, Windows NT 4.0 beta2
> >
> >MFC is reporting memory leaks in module strcore.cpp in
> >CString::AllocBuffer.
> >
> >I am doing normal CString stuff using local variables. Whats going on
> >here? No exceptions have occured, so that not it. Is my program really
> >leaking memory? If so how do I cleanup after an internal CString call =
to
> >AllocCopy?
>=20
> Without some code, it's hard to tell what's causing the leaks.
> Have you checked the KB for articles on CString memory leaks?
>=20
> "Normal CString stuff" is pretty vague, considering what some people th=
ink of as
> "Normal". Are you using GetBuffer()? Are you *sure* all destructors get=
called?
> Are you using templated collections without implementing all the proper=
helper
> functions? And so on..
>=20
> >
> >Object dumps following successive runs of the program seem to indicate
> > that these buffers ARE actually being released (because the address a=
nd
> >size of the memory reported in the object dump is the same over
> >successive runs of the application.)
> >
> >This suggests that either MFC is reporting memory leaks and there are
> >none or MFC / Windows in releasing memory for me.
>=20
> Windows NT will release all memory allocated when your program terminat=
es.
> So you will only accumulate memeory leaks if your program runs for a lo=
ng time.
>=20
> >
> >
> >
> Niels Ull Jacobsen, Kr=FCger A/S (nuj@kruger.dk)
> Everything stated herein is THE OFFICIAL POLICY of the entire Kruger
> group and should be taken as legally binding in every respect.
> Pigs will grow wings and fly.
Dan Kirby -- dkirby@accessone.com
Thursday, August 29, 1996
[Mini-digest: 2 responses]
When MFC/C run-time reports memory leaks, you will see the allocation
number reported in the curly braces. To see which CString is causing the
allocation, simply call _CrtSetBreakAlloc early in your program. The
debugger will stop on that allocation number and then you can look at the
call stack.
--dan
-----From: Jeff Grossman
You also might check if you have any static CString objects laying
around. I had an application once that reported memory leaks in
HeapAgent. I suspected that HeapAgent might be invoked during
program termination before all the destructors for static objects.
I never verified this before being taken off the project, though.
Jeff
| Вернуться в корень Архива
|