topic Re: Uninitialized variable missed? (Parallel Inspector) in Software Archive

Uninitialized variable missed? (Parallel Inspector)

LLess — Tue, 13 Oct 2009 05:20:03 GMT

Am I missing something when I found strange that the Intel Parallel Inspector is not reporting that one?

class testClass
{
public:
testClass() {}

int getVal() {
return val;
}
private:
int val;
};

int a;
int b = a * 4; // uninitialized read of variable a (this one is reported)

b = tc.getVal(); (but not this one).

Obviously the memory hasn't been initialized to anything as far as I am aware, so I would expect it to raise some error here.
Someone (ok me in that test) created the constructor of the class but forgot to initialized the variable (or left it unitialized for some reasons. performance for example).

Thanks.
Laurent.
I am using the Intel Parallel Inspector Update 1, (build 63628) running a x64 debug test on XP64.

Re: Uninitialized variable missed? (Parallel Inspector)

Vladimir_T_Intel — Tue, 13 Oct 2009 08:29:29 GMT

Quoting - laurent lessieux - Toshiba Medical

HiLaurent,

To me it looks like a bug. But let me talk to development team and clarify it.

Re: Uninitialized variable missed? (Parallel Inspector)

Vladimir_T_Intel — Wed, 14 Oct 2009 16:49:04 GMT

Hi Laurent,

Here is the explanation.

First of all, I presume that tc object of the class testClass was created on stack.

Compiled in debug mode:

If debug build was built with stack checking turned on, this initializes the stack with a pattern that is checked by the code. Thus, Inspector will never see uninitialized stack memory, because it is initialized by the compiler.

Compiled in release mode:

If you step through with the debugger, it will show that main is empty. The compiler has optimized out the body because it does nothing.

I slightly modified the sample adding printf("%d",b) in order to prevent compiler optimization of main. In this case Inspector would not report Uninitialized memory access anyway. The reason is the compiler optimization for the creating b variable. For very small numbers of locals, the compiler, when optimizing, will use "push " instructions to reserve space on the stack for local variables. This test is an example of that - the class is basically just an "int". The memory checker doesn't have enough context to recognize that the "push " onto the stack is not "really" writing a value to the stack. Memory checker sees this as initialization, and since this is the stack space used for "b", it doesn't report an Uninitialized memory read.

So, consider this a corner case. If you will face with the problem in the real app case, please let us know, maybe we should reconsider the approach.

Re: Uninitialized variable missed? (Parallel Inspector)

LLess — Thu, 15 Oct 2009 00:26:10 GMT

Hi Vladimir,

It all makes sense thanks.

Indeed the tc object was created on the stack.
I have not tried in release yet so I guess the stack is indeed initialized.
I am looking for the flag to add to turn that off but no luck so far. I am using the Intel Compiler 10.1.29 to compile the test.
Any idea about which flag I should turn off?
I tried /GS- but it is still not finding the issue.

Laurent

Re: Uninitialized variable missed? (Parallel Inspector)

Vladimir_T_Intel — Thu, 15 Oct 2009 12:08:06 GMT

Quoting - laurent lessieux - Toshiba Medical

Hi Laurent,

Just switch off the basic runtime checks (RTC*). Inspector will report uninit read on mi4 level in this case.