Interpret results from "Locate Memory Problems"

Interpret results from "Locate Memory Problems"

Hi,

I try to work with the Intel Inspector to find Memory Problems in the application. Unfortunately I'm not sure how I should interpret the results. Most of the 'Errors' seems to me to be not an error. Please see the sample below, I create a toolbar and assign a bitmap-resource to it. This assignment is indicated to be a "Uninitialized memory access". I'm not sure why this line of code should contain any memory error? Is there any way to avoid that this line is recognized as an memory-error?

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

"Unintialized memory access" means, the memory was used but no value assigned.
I am curious that highlighted line is a MACRO, the tool shouldn't report this error.

Did you use Inspector 2011 or Inspector XE 2011? What is exactbuild number?

Maybe I can construct an example (create toolbar, assign bitmap resource). Are you using MFC?

Regards, Peter

I understand what Uninitialized memory access means I cannot understand the context why the marked lines should be a problem for Inspector XE 2011. I use the MFC and the LoadToolBar function is a member of CToolBar. The parameter is an ID an integer number pointing to a resource of the application. That resource should be loaded and attached to the CToolBar object. It is not a macro!

The inspector build no is 189290.

>>..."Unintialized memory access" means, the memory was used but no value assigned...

Peter, let me make a littlecorrection:

"Unintialized memory access" means, the memory for a variable was allocated but it wasn't initialized before itsfirst use.

It is NOT an error and usually a C/C++ compilergives a warning during compilation. But, at a run-time it could create a problem. Why the Inspector XE 2001 considers it as an error isan enigma for me as well.

Note: A developer could change a compiler's setting to 'Consider a Warning as an Error'.

What I can see these are classic MFC codes for OnCreatemethod. Also, a VERIFY is indeed an MFC'smacro and itis declared in afx.hheader file as:

...
#define VERIFY(f) ASSERT(f)
...

Also,

- 'm_wndToolBar.LoadToolBar( ... )' is a callto LoadToolBar method of CToolBar class;

-m_wndToolBaris a class' member andalways declared in CMainFrame class ( or derivatives ), usually in MainFrm.h header fileas:

class CMainFrame : public CFrameWnd
{
...
protected: // control bar embedded members
CStatusBar m_wndStatusBar;
CToolBar m_wndToolBar;
...
};

PS:
For example,a C/C++ compiler, or the Inspector XE 2011,should give a warning for a line with 'float*pfAddress;' declaration:

...
float*pfAddress;
pfAddress = ( float * )malloc( sizeof( float ) * 32 );
...

if that warning is not disabled with some#pragma directive for a C/C++ compiler.

Asaferway to declare *pfAddress variable is:

...
float*pfAddress = NULL;
pfAddress = ( float * )malloc( sizeof( float ) * 32 );
...

>>...Is there any way to avoid that this line is recognized as an memory-error?..

Hi Daniel,

Please consider a processing for OnCreate methodlike this:

...
int CMainFrame::OnCreate( LPCREATESTRUCT lpCreateStruct )
{
if( CFrameWnd::OnCreate( lpCreateStruct ) == -1 )
return ( int )-1;
...
BOOL bOK = FALSE;

while( TRUE )
{
...
if( m_wndToolBar.LoadToolBar( ... ) == FALSE )
break;
...
bOK = TRUE;
break;
}

...

if( bOK == FALSE )
return ( int )-1;

...

return (int )0;
}
...

Best regards,
Sergey

Hi Sergey,

Thanks a lot for your suggestions. I will give them a try, but I'm not sure that I will change my programming-style just to avoid some strange messages from the Intel-Inspector....!?

Daniel

Login to leave a comment.