Not even close

Not even close

Hi,
I downloaded a trial version, and it sucks.
C++, 64 bit.
I commented out a delete statement as the simple test, and
VS 2010 compiler points to memory leaks, and this expensive tool is way off - points me to some DLLs and
handles that are actually properly disposed of.
I did not change any parameters, just ran "Memory error analysis/detect leaks".
What gives?
Am I doing something wrong?

Please advise,

Thank you

17 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Would it be possible for you to attach the results or give a code sample so thatwe could get a better idea of why you might be seeing this?

Thanks,

One possible issue is IXE only reports unreachable leaks. If there exists some pointer to the allocated memory at program exit, it will not be reported.

You could also try a different analysis type ("Detect Memory Problems" or "Locate Memory Problems"). These use a slightly different instrumentation approach than "Detect Leaks", and may give different results.

Quoting Mark Dewing (Intel)One possible issue is IXE only reports unreachable leaks.If there exists some pointer to the allocated memory at program exit, it will not be reported...
Mark,

I didn't hear anything about Unreachable Leaks. Could you provide aC or C++ test case, please?

Best regards,
Sergey

#include
#include

int *make_unreachable_leak()
{
// Will be reported by Inspector XE
int *tmp = (int *)malloc(sizeof(int));
return NULL;
}

int *make_reachable_leak()
{
// Still accessible through global pointer
// Will not be reported by Inspector XE
int *tmp = (int *)malloc(sizeof(int));
return tmp;
}

int *ptr;

int main(int argc, char **argv)
{

make_unreachable_leak();
ptr = make_reachable_leak();

return 0;
}

Thank you, Mark!

Best regards,
Sergey

Hi Mark,

I'll try to do a follow up onyour Test-Case tomorrow.

Best regards,
Sergey

Quoting Mark Dewing (Intel)...
int *make_reachable_leak()
{
// Still accessible through global pointer
// Will not be reported by Inspector XE

int *tmp = (int *)malloc(sizeof(int));
return tmp;
}
...

Mark,

>>// Will not be reported by Inspector XE

I think it has to be fixed because this is wrong. In both cases memory is allocated from a heap and
a Win32 API function 'HeapAlloc' is used. I will provide two reports from built-in Memory Leaks detection systems
implemented by Microsoft and for the ScaLib project.

Best regards,
Sergey

Here are Test-Cases:

...

RTint *g_iPointer = RTnull;
RTint * MakeUnreachableLeak( RTvoid )							// Will be reported by Inspector XE

{

//	RTint *iTmp = ( RTint * )malloc( sizeof( RTint ) );

//	RTint *iTmp = ( RTint * )new RTint( 777 );

	RTint *iTmp = ( RTint * )CrtNew RTint( 777 );

	return ( RTint * )RTnull;

}

																// Accessible through global pointer

RTint * MakeReachableLeak( RTvoid )								// Will not be reported by Inspector XE

{

//	RTint *iTmp = ( RTint * )malloc( sizeof( RTint ) );

//	RTint *iTmp = ( RTint * )new RTint( 777 );

	RTint *iTmp = ( RTint * )CrtNew RTint( 777 );

	return ( RTint * )iTmp;

}

...
...

// Sub-Test 2.1 - Microsoft MLD

{

	RTbool bOk = RTfalse;
	_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

	_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG | _CRTDBG_MODE_WNDW );
	MakeUnreachableLeak();

	g_iPointer = MakeReachableLeak();
	_CrtDumpMemoryLeaks();

}

...

or

...

// Sub-Test 2.2 - ScaLib MLD

{

	RTbool bOk = RTfalse;
	MakeUnreachableLeak();

	g_iPointer = MakeReachableLeak();
	bOk = MemoryTracerData();

	bOk = MemoryTracerIntegrity();

}

...

Note: MLD stands for Memory Leaks Detection.

Here are results:

>> Microsoft MLD - CRT-function 'malloc' is used <<
...
Detected memory leaks!
Dumping objects ->
{76} normal block at 0x02124470, 4 bytes long.
Data: < > CD CD CD CD
{75} normal block at 0x02124430, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete.
...

>> Microsoft MLD - C++ operator 'new' is used <<
...
Detected memory leaks!
Dumping objects ->
{76} normal block at 0x02124470, 4 bytes long.
Data: < > 09 03 00 00
{75} normal block at 0x02124430, 4 bytes long.
Data: < > 09 03 00 00
Object dump complete.
...

>> ScaLib MLD - C++ operator 'CrtNew' is used ( the same as 'new' ) <<
...
* Memory Block: 0 *
..\common\prttests.cpp(6527)
Memory Block State: 1 - Allocated by CrtNew
* Memory Block: 1 *
..\common\prttests.cpp(6534)
Memory Block State: 1 - Allocated by CrtNew

Memory Blocks Allocated : 2
Memory Blocks Released : 0
Memory Blocks NOT Released: 2
Memory Tracer Integrity Verified - Memory Leaks Detected
...

Please take a look attwo comments.

Quoting Sergey Kostrov>> Microsoft MLD - CRT-function 'malloc' is used <<
...
Detected memory leaks!
Dumping objects ->
{76} normal block at 0x02124470, 4 bytes long.
Data: < > CD CD CD CD
[SergeyK] Not initialized by 'malloc'
...


>> Microsoft MLD - C++ operator 'new' is used <<
...
Detected memory leaks!
Dumping objects ->
{76} normal block at 0x02124470, 4 bytes long.
Data: < > 09 03 00 00
[SergeyK] Initialized with a value 777 ( 0x00000309) by 'new'
...

Best regards,
Sergey

Are there any updates on the problem?

Best regards,
Sergey

I would suggest to use windbg for memory leaks detection, because of large set of commands and very good extensions for example !heap command can you save a lot of pain caused by manually walk the heap.

Here is good tutorial for the memory leaks detection with the help of windbg : http://www.codeproject.com/Articles/31382/Memory-Leak-Detection-Using-Windbg

Quoting iliyapolakI would suggest to use windbg for memory leaks detection, because of large set of commands and very good extensions for example !heap command
can you save a lot of pain caused by manually walk the heap...

In 2007 I worked for an image processingproject and it had more than 30,000 memory leaks...
Some developers / users on the forumare dealing with even more memory leaks, something like 100,000, and
take a look at posts...

WinDbg is a great externalutility but it is not integrated with a Visual Studio IDE by default.

Intel Inspector XE, or Microsoft Memory Leaks Detection ( MLD )API of the CRT library, orScaLib MLD APIare able to point
exactly to a source line where a memory was allocated ( because they could beintergated, or already integrated by default,
withVS IDE )and in that case adeveloper doesn't need to "walk the heap" trying to find something suspicious.

On middle- or large-scale software projects developers arealwaysbusy with completely different things related to
implementation of somenew functionality, or stabilization of some codes, etc.

Here is a short example:

...
* Memory Block: 0 *
..\common\prttests.cpp(6527) [SergeyK]It reports to a line where a new C++ operator was used
Memory Block State: 1 - Allocated by CrtNew
* Memory Block: 1 *
..\common\prttests.cpp(6534) [SergeyK]It reports to a line where a new C++ operator was used
Memory Block State: 1 - Allocated by CrtNew

Memory Blocks Allocated : 2
Memory Blocks Released : 0
Memory Blocks NOT Released: 2
Memory Tracer Integrity Verified - Memory Leaks Detected
...

Best regards,
Sergey

WinDbg is a great externalutility but it is not integrated with a Visual Studio IDE by default

Windbg will be integrated with the next release of Visual Studio.

>>and in that case adeveloper doesn't need to "walk the heap" trying to find something suspicious

@Sergey I was talking from the "debugging" point of view:)

Btw I have used extensively windbg and I must say that this tool is outstanding and very versatile.

>> middle- or large-scale software projects developers arealwaysbusy with completely different things related to
implementation of somenew functionality, or stabilization of some codes

Who is responsible for software - OS interaction debugging when something goes wrongand who do it atmachine code level ?

Please consider it as a programmer'sjoke:

Quoting iliyapolakWho is responsible for software...

A manager... Because he/shetells software developers what they should do and what they shouldn't... :)

Best regards,
Sergey

A manager... Because he/shetells software developers what they should do and what they shouldn't... :)

@Sergey
Do you have an escalation engineers in your team?

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen