 |
|
 |
This would be a nice tool if it worked. I get Unhandled exception in ntdll.dll
|
|
|
|
 |
|
 |
Sorry, this article was written 7 years ago. But 5 years ago I stopped developement and working as consultant. So, I wouldn't help you to fix it Probally we need to find work around for new version of MFC, Vista and x64 mix
|
|
|
|
 |
|
 |
I add the code follow you advice.
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC // include Microsoft memory leak detection procedures
#define _INC_MALLOC // exclude standard memory alloc procedures
#endif
When I compile, it has error:
c:\program files\microsoft visual studio\vc98\atl\include\atlbase.h(2626) : error C2065: 'alloca' : undeclared identifier
CP1Dlg.cpp
thank so much.
safety_ruk
|
|
|
|
 |
|
|
 |
|
|
 |
|
 |
i placed the #defines in stdafx.h, and most source files in my project compiled, but not the ones that included afxpriv.h--these files caused compile errors in malloc.h, for example, when it gets to calloc's prototype, it says:
second C linkage of overloaded function '_calloc_dbg' not allowed
please advise!
ed
|
|
|
|
 |
|
 |
Hello. > Dumping objects -> D:\Projects\CrtDbg\CrtDbg.cpp(25) CrtDbg.cpp(25) is not really leaked point. Instead of this, I leaned another way. -------------------------------------------------------------- #include <stdafx.h> #include <vector> // Insert this code after any include directive #ifdef _DEBUG #define _CRTDBG_MAP_ALLOC #include <crtdbg.h> #define new new(_NORMAL_BLOCK, __FILE__, __LINE__) #endif int main() { // Register leak check after program end _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF |_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)); new int; malloc(10); return 0; } -------------------------------------------------------------- Build it Debug mode and run with Debugger, then IDE report real leaked point like under. Detected memory leaks! Dumping objects -> C:\prj\aaa\aaa.cpp(18) : {51} normal block at 0x00372E98, 10 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD C:\prj\aaa\aaa.cpp(17) : {50} normal block at 0x00372E50, 4 bytes long. Data: < > CD CD CD CD Object dump complete. -- Is this way normal in your environment?
|
|
|
|
 |
|
 |
This works as long as you don't use STD as the macro makes a mess in memory.h
// TEMPLATE OPERATOR new
template
inline void *operator new(size_t _N, std::allocator<_Ty>& _Al)
{return (_Al._Charalloc(_N)); }
Giving:
c:\program files\microsoft visual studio\vc98\include\memory(16) : error C2059: syntax error : 'constant'
c:\program files\microsoft visual studio\vc98\include\memory(17) : error C2091: function returns function
c:\program files\microsoft visual studio\vc98\include\memory(17) : error C2809: 'operator new' has no formal parameters
c:\program files\microsoft visual studio\vc98\include\memory(20) : error C2954: template definitions cannot nest
Does anyone have any ideas how to proceed here ?
Tim.
|
|
|
|
 |
|
 |
Hello, Tim.
You should include all stl headers before macro.
Like this,
#include <memory>
#include <string>
#include <vector>
#include ...
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif
using namespace std;
int main()
{ ...
|
|
|
|
 |
|
 |
Thanks - I'd gone for renaming new so the macro would only be called where needed. But your way is more elegant.
Tim.
|
|
|
|
 |
|
 |
Hi,
I'm writing a DLL and the code looks cool.
So I tried to use the code but there is a problem I don't know to solve. I'm not using a file named stdfax.h. How do I have to implement tho code to use it.
I tried it like this.
//#include "stdafx.h"
//#include "CrtDbg.h"
#include "MemDiff.h"
But this isn't working.
Can anyone help me?
THX
Bjoern
|
|
|
|
 |
|
 |
The memory leaks report a number in curly braces, in the case of the example above it's {53}.
Somewhere in your progam as soon as possible put the command _CrtSetBreakAlloc(53). Obviously exchange that for the memory allocation number reported in your own memory leak. The program with then break execution at exactly the right spot for you to see where the memory was allocated
|
|
|
|
 |
|
 |
I agree extrememly useful and simple.
I tried following MSDN help suggestions using _afxBreakAlloc and couldn't get it to work. Your suggestion fixed my leak problem immediately.
|
|
|
|
 |
|
 |
You've got my 5!!!
Sing when we're programming.
|
|
|
|
 |
|
 |
This is indeed a good tip.
However, even when you have DEBUG_NEW defined you can occasionally still run into problems with the dump not telling you which line the errant block was allocated. Here's an enhancement to the tip for these situations.
Sometimes the number in curly braces varies each time you run your program, however carefully you try to follow the same path. Yet you only find the correct number after it's too late. This makes things a little hard!
My tip is that generally you should have a rough idea where the leak is. You can narrow it down to an extent by commenting out function calls etc., but when this breaks down you can use the following approach.
In my code, I'd worked out (by commenting it out) that the memory leak was always somewhere in the CGraphCtrl::SaveGraphSettings(pOpenFptr); call.
Here's how you get the debugger to break on the line responsible for creating the memory leak:
long allocReqNum;
char *my_pointer;
my_pointer = (char*)malloc(10);
_CrtIsMemoryBlock(my_pointer, 10, &allocReqNum, NULL, NULL);
free(my_pointer); // Breakpoint on first run and note value of allocReqNum
_CrtSetBreakAlloc(allocReqNum+1); // Comment out on first debug run
CGraphCtrl::SaveGraphSettings(pOpenFptr);
When I run it first time I comment out the _CrtSetBreakAlloc call and set a break point after the _CrtIsMemoryBlock call. I then note the allocation number in allocReqNum when the break point is hit.
When the program finishes I look at the memory leaks dump and note the number in curly braces. (If the number in curly braces is lower you need to look earlier in your code's execution!)
Now I can calculate the offset value to add to allocReqNum in the _CrtSetBreakAlloc call - in my example it's '1' - the difference between the number in curly braces in the memory dump and the value I got from akkicReqNum. So I uncomment out the _CrtSetBreakAlloc call and adjust the 'allocReqNum+1' to the correct offset number.
And, finally, now my program will break at the correct allocation point - the one which allocates the memory which is not freed by my program.
Hope this is all clear - if not let me know and I'll try to pen something a little fuller.
I must be slow - it's taken me years, plus the earlier tip, to think of this approach. But hopefully DEBUG_NEW will work for most situations.
|
|
|
|
 |
|
 |
Great tip Peter!
Dealing with big legacy apps it's sometimes difficult to get an associated source file in a memory leak dump. This tip (why didn't I think of that ) is a definite help!
Thank you for taking the time to share it with us
Pierre
|
|
|
|
 |
|
 |
hello :
can u please tell me where to use the code..
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC // include Microsoft memory leak detection procedures
#define _INC_MALLOC // exclude standard memory alloc procedures
#endif
in VC7, i tried to do ot in stdafx.h but i get errors...
thanks
ahmed
|
|
|
|
 |
|
 |
Hello,
I am getting memory leak while terminating the application. as shown below.
--> Detected memory leaks!
0 bytes in 0 Free Blocks.
261307 bytes in 8802 Normal Blocks.
1381 bytes in 7 CRT Blocks.
0 bytes in 0 Ignore Blocks.
784 bytes in 24 Client Blocks.
Largest number used: 6200457 bytes.
Total allocations: 39746600 bytes.
--> Finished track memory leaks
My application is too big and it is not a good idea to look in everywhere , and from this application i found that it shows exact path where memory leak is occuring. but it does not show me. can you help me to detect memory leak where excatly it is occuring.
Thank you very much
|
|
|
|
 |
|
 |
It is indeed a simpler way to detect memory leaks. But I don't have any idea about the following lines. I hope I have solved all the memory leak problem in my application. But still I am getting the following lines and getting error when I am closing my application. This would be a great help for me if you suggest me to analyse the following lines.
Thanks in advance.
HEAP[DialTest.exe]: Invalid Address specified to RtlValidateHeap( 1940000, 1944c80 )
memory check error at 0x01944C9C = 0xEE, should be 0xFD.
memory check error at 0x01944C9D = 0xFE, should be 0xFD.
memory check error at 0x01944C9E = 0xEE, should be 0xFD.
memory check error at 0x01944C9F = 0xFE, should be 0xFD.
First-chance exception in DialTest.exe (MSVCRTD.DLL): 0xC0000005: Access Violation.
Detected memory leaks!
Dumping objects ->
c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {82} normal block at 0x01945328, 14512 bytes long.
Data: < > 1F 00 00 00 00 C0 02 10 00 00 00 00 CD CD CD CD
c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {68} normal block at 0x01944C58, 4 bytes long.
Data: < > 00 00 00 00
{66} client block at 0x01944B08, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $01944B08, 64 bytes long
{59} client block at 0x01942E18, subtype 0, 64 bytes long.
a CDynLinkLibrary object at $01942E18, 64 bytes long
Object dump complete.
|
|
|
|
 |
|
 |
Could anyone tell me how to find the Call stack information from my PROGRAM?
I would like to have a function such as DumpCallStack(). So, in my program, I can write the following:
void sub()
{
int k = 10;
#ifdef _DEBUG
DumpCallStack();
#endif
}
int main()
{
sub();
return 0;
}
If this feature is available, debugging memory leaks will be easier than the following message:
c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {60776} normal block at 0x016472E0, 4 bytes long.
Data: < d > B8 BF 64 01
Thanks ahead!
Best Regards,
Yours,
Ning Cao
|
|
|
|
 |
|
 |
Ning Cao wrote:
Could anyone tell me how to find the Call stack information from my PROGRAM?
Have you done your Googling and searched CP itself before asking? Well, maybe it's easy to miss stuff like this.
|
|
|
|
 |
|
 |
I have searched the keyword "Call Stack" in google.
It gives out many links but most of them are regarding the "Call Stack Window".
Best Regards,
Yours,
Ning Cao
|
|
|
|
 |
|
 |
You can search AfxDumpStack sample in MSDN.
|
|
|
|
 |
|
 |
hi, I think you know a lot of memory management.
Some develop tools has their own memory management modules instead of the standard C/C++ libraries, for example, MSVC using it's debug version libraries to track the memory leaks and memory usage, AutoCAD can track the memory usage of DLLs(most are created by others) and found memory leaks.
Could you tell me how to implemente this feature in my own program or just some references ?
Thanks ahead.
Best Regards,
Yours,
Ning Cao
|
|
|
|
 |
|
 |
I tried you the following defenition for detecting memory leaks:
/////////////////////////////////////////////////////////////
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#define _INC_MALLOC
extern "C"
{
void * __cdecl _alloca(size_t);
#define alloca _alloca
}
#endif
#include
#include
//////////////////////////////////////////////////
i get the following loaction:
c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552)
I use ATL com environment.
It would be great help for me if anyone have improved solution
Yud
|
|
|
|
 |