Memory leaks
in [MFC]
|
From: GT on 20 May 2008 11:28 Visual Studio 2005. I have memory leaks in my project. I seem have 7 objects that are not being destroyed properly. The memory locations being left behind are the same everytime. Can I find out when these objects are being created so that I can figure out what they are? Thanks, GT This is the output window info: f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9760} normal block at 0x01E739C0, 37 bytes long. Data: <, ?x > 2C 08 3F 78 14 00 00 00 14 00 00 00 01 00 00 00 f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9759} normal block at 0x01E73960, 33 bytes long. Data: <, ?x > 2C 08 3F 78 10 00 00 00 10 00 00 00 01 00 00 00 f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9758} normal block at 0x01E6F6E0, 17 bytes long. Data: <, ?x > 2C 08 3F 78 00 00 00 00 00 00 00 00 01 00 00 00 f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9757} normal block at 0x01E738F8, 43 bytes long. Data: <, ?x > 2C 08 3F 78 1A 00 00 00 1A 00 00 00 01 00 00 00 f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9756} normal block at 0x01E733B0, 24 bytes long. Data: <, ?x > 2C 08 3F 78 07 00 00 00 07 00 00 00 01 00 00 00 f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9755} normal block at 0x01E73198, 25 bytes long. Data: <, ?x > 2C 08 3F 78 08 00 00 00 08 00 00 00 01 00 00 00
From: Doug Harrison [MVP] on 20 May 2008 11:38 On Tue, 20 May 2008 16:28:11 +0100, "GT" <ContactGT_removeme_(a)hotmail.com> wrote: >Visual Studio 2005. > >I have memory leaks in my project. I seem have 7 objects that are not being >destroyed properly. The memory locations being left behind are the same >everytime. Can I find out when these objects are being created so that I can >figure out what they are? > >Thanks, >GT > > >This is the output window info: > >f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9760} normal >block at 0x01E739C0, 37 bytes long. > Data: <, ?x > 2C 08 3F 78 14 00 00 00 14 00 00 00 01 00 00 00 >f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9759} normal >block at 0x01E73960, 33 bytes long. > Data: <, ?x > 2C 08 3F 78 10 00 00 00 10 00 00 00 01 00 00 00 >f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9758} normal >block at 0x01E6F6E0, 17 bytes long. > Data: <, ?x > 2C 08 3F 78 00 00 00 00 00 00 00 00 01 00 00 00 >f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9757} normal >block at 0x01E738F8, 43 bytes long. > Data: <, ?x > 2C 08 3F 78 1A 00 00 00 1A 00 00 00 01 00 00 00 >f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9756} normal >block at 0x01E733B0, 24 bytes long. > Data: <, ?x > 2C 08 3F 78 07 00 00 00 07 00 00 00 01 00 00 00 >f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9755} normal >block at 0x01E73198, 25 bytes long. > Data: <, ?x > 2C 08 3F 78 08 00 00 00 08 00 00 00 01 00 00 00 See if this helps: How to use _crtBreakAlloc to debug a memory allocation http://support.microsoft.com/kb/151585 -- Doug Harrison Visual C++ MVP
From: Giovanni Dicanio on 20 May 2008 11:45 "GT" <ContactGT_removeme_(a)hotmail.com> ha scritto nel messaggio news:018a39e1$0$13087$c3e8da3(a)news.astraweb.com... > I have memory leaks in my project. I seem have 7 objects that are not > being destroyed properly. The memory locations being left behind are the > same everytime. Can I find out when these objects are being created so > that I can figure out what they are? [...] > This is the output window info: > > f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9760} normal > block at 0x01E739C0, 37 bytes long. I don't have VS7 so I don't know what is in strcore.cpp at line 141... You should double-click on the line in the output window which shows the file name and line number... It seems something related to CString ('strcore.cpp')... How do you create the CString instances in your code? Are they stored in some class (as data member) and instances of that class are not properly destructed? If you create objects with 'new', pay attention to proper 'delete's... Or better, use some smart pointer class (like shared_ptr when object ownership is shared, or auto_ptr for simpler scenarios...) Moreover, you may want to read that: "How to: Set Breakpoints on a Memory Allocation Number" http://msdn.microsoft.com/en-us/library/w2fhc9a3.aspx HTH, Giovanni
From: GT on 20 May 2008 12:01 "Doug Harrison [MVP]" <dsh(a)mvps.org> wrote in message news:m0s534dqe1ihrculuaqc54g2ic5888lbe5(a)4ax.com... > On Tue, 20 May 2008 16:28:11 +0100, "GT" <ContactGT_removeme_(a)hotmail.com> > wrote: > >>Visual Studio 2005. >> >>I have memory leaks in my project. I seem have 7 objects that are not >>being >>destroyed properly. The memory locations being left behind are the same >>everytime. Can I find out when these objects are being created so that I >>can >>figure out what they are? >> >>Thanks, >>GT >> >> >>This is the output window info: >> >>f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9760} normal >>block at 0x01E739C0, 37 bytes long. >> Data: <, ?x > 2C 08 3F 78 14 00 00 00 14 00 00 00 01 00 00 00 >>f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9759} normal >>block at 0x01E73960, 33 bytes long. >> Data: <, ?x > 2C 08 3F 78 10 00 00 00 10 00 00 00 01 00 00 00 >>f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9758} normal >>block at 0x01E6F6E0, 17 bytes long. >> Data: <, ?x > 2C 08 3F 78 00 00 00 00 00 00 00 00 01 00 00 00 >>f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9757} normal >>block at 0x01E738F8, 43 bytes long. >> Data: <, ?x > 2C 08 3F 78 1A 00 00 00 1A 00 00 00 01 00 00 00 >>f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9756} normal >>block at 0x01E733B0, 24 bytes long. >> Data: <, ?x > 2C 08 3F 78 07 00 00 00 07 00 00 00 01 00 00 00 >>f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {9755} normal >>block at 0x01E73198, 25 bytes long. >> Data: <, ?x > 2C 08 3F 78 08 00 00 00 08 00 00 00 01 00 00 00 > > See if this helps: > > How to use _crtBreakAlloc to debug a memory allocation > http://support.microsoft.com/kb/151585 Thanks - I think that is Pre VS 2005 - mine doesn't recognise those commands in the watch window! I found that I can add a breakpoint when a place in memory changes, but its not my code that it being hit when the breakpoint triggers - have I found a memory leak in the MFC code?!? Anothe thing that is confusing me - the above output window information suggests that the MFC CPP classes are on drive F:, but I have no drive F:. Could this be related to the memory leaks somehow??
From: Doug Harrison [MVP] on 20 May 2008 12:32
On Tue, 20 May 2008 17:01:03 +0100, "GT" <ContactGT_removeme_(a)hotmail.com> wrote: >> How to use _crtBreakAlloc to debug a memory allocation >> http://support.microsoft.com/kb/151585 > >Thanks - I think that is Pre VS 2005 - mine doesn't recognise those commands >in the watch window! I found that I can add a breakpoint when a place in >memory changes, but its not my code that it being hit when the breakpoint >triggers - have I found a memory leak in the MFC code?!? As the article says, you can use _CrtSetBreakAlloc and recompile, or you can use the watch window. To use the latter, I suppose you may have to determine the name of the CRT DLL VC2005 is using. You should be able to find its name in the output window, in the list of DLLs your program has loaded. >Anothe thing that is confusing me - the above output window information >suggests that the MFC CPP classes are on drive F:, but I have no drive F:. >Could this be related to the memory leaks somehow?? Are you using any third party libraries? In any event, you'll be able to figure out what's going on once you set an allocation breakpoint and examine the call stack when you break. -- Doug Harrison Visual C++ MVP |