Discussion:
why I can't see file and line number when try to detect memory leak?
(too old to reply)
Vivienne
2007-09-17 06:35:16 UTC
Permalink
Hi,

I detect memory leaking in my application, like this,

Detected memory leaks!
Dumping objects ->
{895} normal block at 0x043B0B60, 44 bytes long.
Data: < g, > i K> A9 EB 67 2C 99 A5 9A 81 3E 99 69 00 9A FB B7
4B
{890} normal block at 0x043B09D0, 17 bytes long.
Data: <i iDu u_9g > 69 14 0B BE 9D 69 44 75 F6 75 5F 39 67 87 94
8F
{876} normal block at 0x043B0CB0, 29 bytes long.
......................................

but, it doesn't show me the file and the line number where the memory
was allocated.
I followed MSDN instructions, and placed the following lines in my
application:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

and expected to get the display like this:
Detected memory leaks!
Dumping objects ->
C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\leaktest\leaktest.cpp(20) :
{18}
normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
CD
Object dump complete.


but this didn't make any change.I can't the the expected display.
Then what is wrong? what should I do?

Thanks!

Vivienne

then, how can't I make it display the file and line numbers
Giovanni Dicanio
2007-09-17 08:11:51 UTC
Permalink
Post by Vivienne
I detect memory leaking in my application, like this,
Detected memory leaks!
Dumping objects ->
{895} normal block at 0x043B0B60, 44 bytes long.
Data: < g, > i K> A9 EB 67 2C 99 A5 9A 81 3E 99 69 00 9A FB B7
4B
{890} normal block at 0x043B09D0, 17 bytes long.
Data: <i iDu u_9g > 69 14 0B BE 9D 69 44 75 F6 75 5F 39 67 87 94
8F
{876} normal block at 0x043B0CB0, 29 bytes long.
......................................
but, it doesn't show me the file and the line number where the memory
was allocated.
What is important in the above debug information are the block IDs
(e.g.{895}, {890}, ...). These numbers are the memory allocation numbers,
and they help you finding the memory leaks.

In the Watch window, you can insert in the Name column the string
"_crtBreakAlloc".
If you are using the multithreaded DLL, you should specify the context
operator like so:

{,,msvcr71d.dll}_crtBreakAlloc

Then press RETURN key.

Then put in the Value column the allocation number that you want to
investigate, e.g. 895.

Then you continue debugging.

Then your program will break at specified allocation number. So, you can
look at the Call Stack window, to understand when and where the memory was
allocated.

Giovanni
Vivienne
2007-09-17 10:55:30 UTC
Permalink
Hi, Giovanni
Post by Giovanni Dicanio
What is important in the above debug information are the block IDs
(e.g.{895}, {890}, ...). These numbers are the memory allocation numbers,
and they help you finding the memory leaks.
In the Watch window, you can insert in the Name column the string
"_crtBreakAlloc".
If you are using the multithreaded DLL, you should specify the context
{,,msvcr71d.dll}_crtBreakAlloc
Then press RETURN key.
Then put in the Value column the allocation number that you want to
investigate, e.g. 895.
here, I got the response: _crtBreakAlloc CXX0017: Error: symbol
"_crtBreakAlloc" not found
I can't get the value of it.
why?
Giovanni Dicanio
2007-09-17 14:22:53 UTC
Permalink
Post by Vivienne
Post by Giovanni Dicanio
{,,msvcr71d.dll}_crtBreakAlloc
Then press RETURN key.
Then put in the Value column the allocation number that you want to
investigate, e.g. 895.
here, I got the response: _crtBreakAlloc CXX0017: Error: symbol
"_crtBreakAlloc" not found
I can't get the value of it.
why?
Hi Vivienne,

which version of Visual C++ are you using?

I did the test for VC++7.1 (VS.NET 2003), but maybe you are using VS2005 so
the explicit reference to msvcr71d.dll is wrong for that IDE...

You might try to remove the sub-string in {...}, and see if that works...

Or maybe you should try to explicitly call _CrtSetBreakAlloc at the
beginning of your code, as Igor T. has suggested in his recent post.

Giovanni
Vivienne
2007-09-18 01:22:38 UTC
Permalink
Hi, Giovanni

I am using VS2005, so I shouldn't refer msvcr71d.dll.
Anyway, _CrtSetBreakAlloc() does work!
Thank you!
Post by Giovanni Dicanio
I did the test for VC++7.1 (VS.NET 2003), but maybe you are using VS2005 so
the explicit reference to msvcr71d.dll is wrong for that IDE...
You might try to remove the sub-string in {...}, and see if that works...
Or maybe you should try to explicitly call _CrtSetBreakAlloc at the
beginning of your code, as Igor T. has suggested in his recent post.
Giovanni
Giovanni Dicanio
2007-09-18 08:22:15 UTC
Permalink
Post by Vivienne
Hi, Giovanni
I am using VS2005, so I shouldn't refer msvcr71d.dll.
Anyway, _CrtSetBreakAlloc() does work!
Thank you!
If you are using VS2005, you may try referring to msvcr80d.dll, i.e. put
this string into the watch window:

{,,msvcr80d.dll}_crtBreakAlloc

and then change the -1 into the number of allocation block you want to
investigate (and then press F5 and the debugger should break when the
particular allocation is hit).

Giovanni

Bill Davy
2007-09-17 08:35:41 UTC
Permalink
Post by Vivienne
Hi,
I detect memory leaking in my application, like this,
Detected memory leaks!
Dumping objects ->
{895} normal block at 0x043B0B60, 44 bytes long.
Data: < g, > i K> A9 EB 67 2C 99 A5 9A 81 3E 99 69 00 9A FB B7
4B
{890} normal block at 0x043B09D0, 17 bytes long.
Data: <i iDu u_9g > 69 14 0B BE 9D 69 44 75 F6 75 5F 39 67 87 94
8F
{876} normal block at 0x043B0CB0, 29 bytes long.
......................................
but, it doesn't show me the file and the line number where the memory
was allocated.
I followed MSDN instructions, and placed the following lines in my
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
Detected memory leaks!
Dumping objects ->
{18}
normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
CD
Object dump complete.
but this didn't make any change.I can't the the expected display.
Then what is wrong? what should I do?
Thanks!
Vivienne
then, how can't I make it display the file and line numbers
I have the foillowing chunk in a VC6 application:

#define malloc(__nNumberOfBytesToMalloc) \
_malloc_dbg(__nNumberOfBytesToMalloc, _NORMAL_BLOCK, __FILE__,
__LINE__);
Aurelien Regat-Barrel
2007-09-17 10:09:35 UTC
Permalink
Post by Vivienne
Hi,
Hi Vivienne,
Post by Vivienne
I detect memory leaking in my application, like this,
Detected memory leaks!
Dumping objects ->
{895} normal block at 0x043B0B60, 44 bytes long.
Data: < g, > i K> A9 EB 67 2C 99 A5 9A 81 3E 99 69 00 9A FB B7
4B
{890} normal block at 0x043B09D0, 17 bytes long.
Data: <i iDu u_9g > 69 14 0B BE 9D 69 44 75 F6 75 5F 39 67 87 94
8F
{876} normal block at 0x043B0CB0, 29 bytes long.
......................................
but, it doesn't show me the file and the line number where the memory
was allocated.
I followed MSDN instructions, and placed the following lines in my
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
Detected memory leaks!
Dumping objects ->
{18}
normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
CD
Object dump complete.
but this didn't make any change.I can't the the expected display.
Then what is wrong? what should I do?
It is not surprising if the memory was allocated with new. You have to
define a replacement for operator new, like this:
#define new new( _CLIENT_BLOCK, __FILE__, __LINE__)
Post by Vivienne
then, how can't I make it display the file and line numbers
The last time I had to deal with this, I added the following lines in
the PCH:

#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#define new new(_CLIENT_BLOCK, __FILE__, __LINE__)
#endif

and it worked (after recompilation).

Aurelien
Vivienne
2007-09-17 11:02:31 UTC
Permalink
hi, Aurelien
Post by Aurelien Regat-Barrel
It is not surprising if the memory was allocated with new. You have to
#define new new( _CLIENT_BLOCK, __FILE__, __LINE__)
The last time I had to deal with this, I added the following lines in
#ifdef _DEBUG
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#define new new(_CLIENT_BLOCK, __FILE__, __LINE__)
#endif
I tried your method, but I got too many compliling errors. the first
of them is that "operation new is duplicated defined".
I think I must missed something. But what is it?
Aurelien Regat-Barrel
2007-09-18 05:16:26 UTC
Permalink
Post by Vivienne
Post by Aurelien Regat-Barrel
It is not surprising if the memory was allocated with new. You have to
#define new new( _CLIENT_BLOCK, __FILE__, __LINE__)
[...]
Post by Vivienne
I tried your method, but I got too many compliling errors. the first
of them is that "operation new is duplicated defined".
I think I must missed something. But what is it?
Each occurrence of the word "new" will be replaced by the macro. So if
you use it in the context of redefining the new operator for example,
this trick may not be suitable for you. Or you will have to adapt it for
each source file instead of using the PCH (as the MFC do -> #define new
DEBUG_NEW).
--
Aurelien Regat-Barrel
Igor Tandetnik
2007-09-17 12:30:35 UTC
Permalink
Post by Vivienne
I detect memory leaking in my application, like this,
Detected memory leaks!
Dumping objects ->
{895} normal block at 0x043B0B60, 44 bytes long.
Data: < g, > i K> A9 EB 67 2C 99 A5 9A 81 3E 99 69 00 9A FB B7
4B
{890} normal block at 0x043B09D0, 17 bytes long.
Data: <i iDu u_9g > 69 14 0B BE 9D 69 44 75 F6 75 5F 39 67 87 94
8F
{876} normal block at 0x043B0CB0, 29 bytes long.
......................................
but, it doesn't show me the file and the line number where the memory
was allocated.
At the beginning of your program, call _CrtSetBreakAlloc(876) (where 876
is the allocation number as reported by the dump). Run the program under
debugger - it will break when this allocation is made. You can then use
the call stack to figure out where in your code memory is allocated.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Continue reading on narkive:
Loading...