Not even close

Not even close

imagem de namsaray

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 posts / 0 new
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.
imagem de Holly Wilper (Intel)

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,

imagem de 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.

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.

imagem de Sergey Kostrov
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

imagem de mark-dewing (Intel)

#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;
}

imagem de Sergey Kostrov

Thank you, Mark!

Best regards,
Sergey

imagem de Sergey Kostrov

Hi Mark,

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

Best regards,
Sergey

imagem de Sergey Kostrov
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

imagem de Sergey Kostrov

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();

}

...

imagem de Sergey Kostrov

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
...

imagem de Sergey Kostrov
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

imagem de Sergey Kostrov

Are there any updates on the problem?

Best regards,
Sergey

imagem de iliyapolak

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

imagem de Sergey Kostrov
Quoting iliyapolak 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...

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

imagem de iliyapolak

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 ?

imagem de Sergey Kostrov
Please consider it as a programmer'sjoke:

Quoting iliyapolak Who is responsible for software...

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

Best regards,
Sergey

imagem de iliyapolak

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?

Faça login para deixar um comentário.