where to warn about uninitialized data

[kcc]

Hello,

I just tried the memory error detector on the following test:

int main() {

char *foo = (char*)malloc(100);

char *bar = (char*)malloc(100);

memcpy(bar, foo, 100);

free(bar);

free(foo);

return 0;

}

The tool complains about uninitialized use inside memcpy().

So, this tool issues a warning when there is any read of uninitialized data.

Valgrind/Memcheck behaves differently: it only warns if the uninitialized data was used to generate a side effect (e.g. a branch depends on the uninitialized data).

Is there a way to make the intel memory checker behave like valgrind/memcheck?

The current behavior makes the tool useless due to a large number of false positives.

Thanks!

--kcc

[Vladimir_T_Intel]

Quoting - kcc

Hello,

I just tried the memory error detector on the following test:

int main() {

char *foo = (char*)malloc(100);

char *bar = (char*)malloc(100);

memcpy(bar, foo, 100);

free(bar);

free(foo);

return 0;

}

The tool complains about uninitialized use inside memcpy().

So, this tool issues a warning when there is any read of uninitialized data.

Valgrind/Memcheck behaves differently: it only warns if the uninitialized data was used to generate a side effect (e.g. a branch depends on the uninitialized data).

Is there a way to make the intel memory checker behave like valgrind/memcheck?

The current behavior makes the tool useless due to a large number of false positives.

Thanks!

--kcc

Hi,

Thanks for your test case.

Inspector does not generate the error until the highest mi4 level is used for analysis. We believe we should report such cases right away at least on the highest level. On the intermediate levels the problem is reported if the uninitialized data affect correctness.

If you do not want to see such error reports on the mi4 level, use suppressions. In the Details view of the results, select 'Read' observation for this problem, mouse right-click, and choose 'Supress...' in the context menu. In the private suppression dialog create a filter with 'Uninitialized memory access' problem and 'Read' and/or 'Allocation site' description. For all other columns (module, function, etc.) set * (all).

Next time before launching analysis in the analysis type selection dialog choose 'Private Suppressions: Delete problems' in the drop-down menu. The error will not appear after analysis is completed.

[kcc]

But on mi3 I don't see a report where I would expect to have it:

int main() {
char *foo = (char*)malloc(100);
char *bar = (char*)malloc(100);
memcpy(bar, foo, 100);
printf("%cn", bar[100]); // <<< added this line
free(bar);
free(foo);
return 0;
}

[Vladimir_T_Intel]

Quoting - kcc

But on mi3 I don't see a report where I would expect to have it:

int main() {
char *foo = (char*)malloc(100);
char *bar = (char*)malloc(100);
memcpy(bar, foo, 100);
printf("%cn", bar[100]); // <<< added this line
free(bar);
free(foo);
return 0;
}

Kostya,

I'm using Intel Parallel Inspector v.1.0 Update1 and I see the error report ;)

Which version you were using?

[kcc]

We use "Product version: 9.0.0.55494", downloaded few weeks ago.

[Vladimir_T_Intel]

Quoting - kcc

We use "Product version: 9.0.0.55494", downloaded few weeks ago.

This is not the Update1 build. Inspector 1.0 Update1 starts from 63628. Please, try the latest version form IRC.

[kcc]

Quoting - Vladimir Tsymbal (Intel)

This is not the Update1 build. Inspector 1.0 Update1 starts from 63628. Please, try the latest version form IRC.

The code should be this:

#include
#include
#include

int main() {
char *foo = (char*)malloc(100);
//printf("%cn", foo[10]);
char *bar = (char*)malloc(100);
memcpy(bar, foo, 100);
printf("zzz%cn", bar[10]);
free(bar);
free(foo);
return 0;
}

mi3 is silent, mi4 reports a warning inside memcpy(). Bad.

[Vladimir_T_Intel]

Yes,
printf("%cn", bar[100]); // <<< added this line

is a separate bug - Invalid memory access. And it will be reported on each level mi2-mi4

Quoting - kcc

mi3 is silent, mi4 reports a warning inside memcpy(). Bad.

This is the intention to report error (not warning) on the level mi4. You can suppress them easily. What exactly is bad?

[kcc]

Quoting - Vladimir Tsymbal (Intel)

This is the intention to report error (not warning) on the level mi4. You can suppress them easily. What exactly is bad?

Valgrind/memcheck reports UMR errors only on real use, no when the memory is copied around.

I believe this is the only right way.

A program may have structures with uninted parts due to alignment or bitfields.

For all such cases the inspector will issue false reports which will need to be suppressed.

Suppressing false reports is time consuming (even if partially automated) and easily leads to missing real bugs.

So, the question remains: is it possible to implement a switch such that the inspector will behave like memcheck?

[Vladimir_T_Intel]

Quoting - kcc

Valgrind/memcheck reports UMR errors only on real use, no when the memory is copied around.

I believe this is the only right way.

A program may have structures with uninted parts due to alignment or bitfields.

For all such cases the inspector will issue false reports which will need to be suppressed.

Suppressing false reports is time consuming (even if partially automated) and easily leads to missing real bugs.

So, the question remains: is it possible to implement a switch such that the inspector will behave like memcheck?

Let's summarize:

1. Suppression approach is time consuming - as I explained earlier it can be configured in a minute and reused in any further analysis.

2. Suppression easily leads to missing real bugs -we need a real example to prove that. If this is the case, we might change the approach.

3. Implementing a switch such that the inspector will behave like Valgrind/memcheck - at the moment Inspector behaves the same way on mi2-mi3 levels. For mi4 you need to switch 'Private Suppressions: Delete problems' on.

If there are more concerns, please share them.

[kcc]

Here is a completely valid C++ program on which mi4 complains.


-----------------------------
#include

struct Foo {
double a;
char b;
double c;
};

int main() {
Foo f1;
f1.a = 0.0;
f1.b = 'b';
f1.c = 9.0;
Foo f2 = f1; // <<<<<<<<<<< mi4 reports error here
printf ("%f %c %fn", f2.a, f2.b, f2.c);
return 0;
}

[Vladimir_T_Intel]

Quoting - kcc

Here is a completely valid C++ program on which mi4 complains.


-----------------------------
#include

struct Foo {
double a;
char b;
double c;
};

int main() {
Foo f1;
f1.a = 0.0;
f1.b = 'b';
f1.c = 9.0;
Foo f2 = f1; // <<<<<<<<<<< mi4 reports error here
printf ("%f %c %fn", f2.a, f2.b, f2.c);
return 0;
}

No errors reported. I needthe binaryand pdb to reproduce it.

[Vladimir_T_Intel]

Quoting - Vladimir Tsymbal (Intel)

No errors reported. I needthe binaryand pdb to reproduce it.

Ok.received the project by e-mail. Looks like the different default compiler settings.

I see the problem now and I can't guarantee that we fix it soon as the approach in Inspector MCdiffers from the other tools. Will let you know the results of further invesigation.

Thanks a lot for raisng the problem.