Memory Leak Part II
-
With the help of "Superman", I was able to prevent all but one memory leak generated by the 'new' operator: {164} client block at 0x00187CA0, subtype c0, 28 bytes long. a CObject object at $00187CA0, 28 bytes long Questions: 1. I understand most of what the Visual Studio 2008 teaches. Am I doing something incorrectly to generate this leak? 2. Do I have to do something with this, or will the memory be released upon exiting Visual Studio. There are several 'normal block' memory leaks also indicated. They take the form of: f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {166} normal block at 0x00187D68, 28 bytes long. Data: <, e > 2C FB 16 65 05 00 00 00 05 00 00 00 01 00 00 00 Questions: 1. This appears to be generated inside an executable supplied by Visual Studio. Is this a Microsoft "bug"? If so, what am I doing to cause this and others of similar form? 2. Same question as #2 above. 3. FWIW, my System Disk Management dialog shows "f:\" as one of my DVD reader/writers. Does Visual Studion "count noses" differently than Vista 64 does?:confused::confused: Thanks again, Barry
-
With the help of "Superman", I was able to prevent all but one memory leak generated by the 'new' operator: {164} client block at 0x00187CA0, subtype c0, 28 bytes long. a CObject object at $00187CA0, 28 bytes long Questions: 1. I understand most of what the Visual Studio 2008 teaches. Am I doing something incorrectly to generate this leak? 2. Do I have to do something with this, or will the memory be released upon exiting Visual Studio. There are several 'normal block' memory leaks also indicated. They take the form of: f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {166} normal block at 0x00187D68, 28 bytes long. Data: <, e > 2C FB 16 65 05 00 00 00 05 00 00 00 01 00 00 00 Questions: 1. This appears to be generated inside an executable supplied by Visual Studio. Is this a Microsoft "bug"? If so, what am I doing to cause this and others of similar form? 2. Same question as #2 above. 3. FWIW, my System Disk Management dialog shows "f:\" as one of my DVD reader/writers. Does Visual Studion "count noses" differently than Vista 64 does?:confused::confused: Thanks again, Barry
BarryPearlman wrote:
{164} client block at 0x00187CA0, subtype c0, 28 bytes long. a CObject object at $00187CA0, 28 bytes long
You could add the following to the beginning of your source files (after inclusion of all header files) so that the debugger will be able to pinpoint the memory which is leaking (line number and source file name).
#ifdef _DEBUG
#define new DEBUG_NEW
#endifOf course you should build in debug mode in order for this to work.
“Follow your bliss.” – Joseph Campbell
-
With the help of "Superman", I was able to prevent all but one memory leak generated by the 'new' operator: {164} client block at 0x00187CA0, subtype c0, 28 bytes long. a CObject object at $00187CA0, 28 bytes long Questions: 1. I understand most of what the Visual Studio 2008 teaches. Am I doing something incorrectly to generate this leak? 2. Do I have to do something with this, or will the memory be released upon exiting Visual Studio. There are several 'normal block' memory leaks also indicated. They take the form of: f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {166} normal block at 0x00187D68, 28 bytes long. Data: <, e > 2C FB 16 65 05 00 00 00 05 00 00 00 01 00 00 00 Questions: 1. This appears to be generated inside an executable supplied by Visual Studio. Is this a Microsoft "bug"? If so, what am I doing to cause this and others of similar form? 2. Same question as #2 above. 3. FWIW, my System Disk Management dialog shows "f:\" as one of my DVD reader/writers. Does Visual Studion "count noses" differently than Vista 64 does?:confused::confused: Thanks again, Barry
BarryPearlman wrote:
Am I doing something incorrectly to generate this leak?
Probably.
BarryPearlman wrote:
will the memory be released upon exiting Visual Studio
Yes, but if the object holds system resources they may not (won't) be cleaned up properly.
BarryPearlman wrote:
Is this a Microsoft "bug"?
No, that's just where the actual alloc was called, but higher in the call stack you asked it to do something that resulted in the alloc. Chances are you have either allocated (or done something that resulted in an alloc) that you haven't cleaned up, or you have a global object that is being constructed after you set the 1st crt mem checkpoint, but being destroyed after the 2nd crt mem checkpoint e.g. a function level static object.
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
-
BarryPearlman wrote:
{164} client block at 0x00187CA0, subtype c0, 28 bytes long. a CObject object at $00187CA0, 28 bytes long
You could add the following to the beginning of your source files (after inclusion of all header files) so that the debugger will be able to pinpoint the memory which is leaking (line number and source file name).
#ifdef _DEBUG
#define new DEBUG_NEW
#endifOf course you should build in debug mode in order for this to work.
“Follow your bliss.” – Joseph Campbell
Worked like a charm; all leaks stopped to date. I haven't touched C++ & MFC in years and I forgot the basic rule of "when you are done with your crayons, put them away!" Thanks for your reply. Barry :)
-
Worked like a charm; all leaks stopped to date. I haven't touched C++ & MFC in years and I forgot the basic rule of "when you are done with your crayons, put them away!" Thanks for your reply. Barry :)
BarryPearlman wrote:
Worked like a charm; all leaks stopped to date. I haven't touched C++ & MFC in years and I forgot the basic rule of "when you are done with your crayons, put them away!" Thanks for your reply
I'm glad to be of help. It would be great if you could mark the helpful answers (by clicking "Good Answer") and close your thread.
“Follow your bliss.” – Joseph Campbell