- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - laurent lessieux - Toshiba Medical
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.
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.
HiLaurent,
To me it looks like a bug. But let me talk to development team and clarify it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - laurent lessieux - Toshiba Medical
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
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
Hi Laurent,
Just switch off the basic runtime checks (RTC*). Inspector will report uninit read on mi4 level in this case.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page