false positive in inspector/mi4 (?)

false positive in inspector/mi4 (?)

I have a simple test where inspector/mi4 reports ' Uninitialized memory access problem(s)' inside STL object.
It looks like this is a false positive, probably related tohttp://software.intel.com/en-us/forums/showthread.php?t=68849
The test is a minimized reproducer of a problem in a real program.

The error is reported somewhere deep inside STL, invec.push_back(str);

Please comment.
Thanks.

c:Userskcccxxstring_vector_test>type string_vector_test.cpp
#include "stdlib.h"
#include "stdio.h"
#include
#include

using std::string;
using std::vector;

int main(int argc, char **argv) {
string str;
vector vec;
for (int i = 0; i < 1000; i++) {
char buff[100];
sprintf(buff, "%d", i);
string str(buff);
vec.push_back(str);
}
printf("string_vector_test: donen");
return 0;
}

c:Userskcccxxstring_vector_test>cl /Zi string_vector_test.cpp
Microsoft 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

string_vector_test.cpp
C:Program Files (x86)Microsoft Visual Studio 9.0VCINCLUDExlocale(342) : war
ning C4530: C++ exception handler used, but unwind semantics are not enabled. Sp
ecify /EHsc
Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:string_vector_test.exe
/debug
string_vector_test.obj

c:Userskcccxxstring_vector_test>string_vector_test.exe
string_vector_test: done

c:Userskcccxxstring_vector_test>"C:Program Files (x86)IntelParallel Studi
oInspectorbin32"insp-cl.exe -collect mi4 string_vector_test.exe
string_vector_test: done

c:Userskcccxxstring_vector_test>type r000mi4insp-cl.txt

=== Start: [2009/10/22 14:47:45] ===
Used suppression file(s): []
6 new problem(s) found
6 Uninitialized memory access problem(s) detected
=== End: [2009/10/22 14:47:56] ===

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

Even smaller reproducer. The warning comes from the second 'push_back' line.

#include "stdio.h"
#include
#include
int main(int argc, char **argv) {
std::vector vec;
vec.push_back("first string");
vec.push_back("second string");
printf("string_vector_test: donen");
return 0;
}

The report is:

Read Call Stack:

string_vector_test.exe!swap
xstring:1745
string_vector_test.exe!swap,class std::allocator >
xstring:2206
string_vector_test.exe!_Swap_adl,class std::allocator > >
utility:31
string_vector_test.exe!_Uninit_move,class std::allocator > *,class std::basic_string,class std::allocator > *,class std::allocator,class std::allocator > > >
memory:225
string_vector_test.exe!_Unchecked_uninitialized_move,class std::allocator > *,class std::basic_string,class std::allocator > *,class std::allocator,class std::allocator > > >
memory:864
string_vector_test.exe!_Umove,class std::allocator > *>
vector:1148
string_vector_test.exe!_Insert_n
vector:1181
string_vector_test.exe!insert
vector:877
string_vector_test.exe!push_back
vector:823
string_vector_test.exe!main
string_vector_test.cpp:7

Allocation call stack:

string_vector_test.exe!_Allocate,class std::allocator > >
xmemory:43
string_vector_test.exe!allocate
xmemory:145
string_vector_test.exe!_Insert_n
vector:1173
string_vector_test.exe!insert
vector:877
string_vector_test.exe!push_back
vector:823
string_vector_test.exe!main
string_vector_test.cpp:7

Sorry for the delay in responding. We are investigating your issue, and will have a reply shortly.

Geoff

Quoting - Geoffrey Burling (Intel)

Sorry for the delay in responding. We are investigating your issue, and will have a reply shortly.

Geoff

After investigation, we determined that Intel Parallel Inspector is doing the correct thing here. There is an instance in the STL code where an uninitalized variable is used. (A possible clue why that is the case is the name of thefunction -- _Unchecked_Uninitialized_move.) However, this is a benign error, so it can be safely filtered out by the end user. However, I have reported this issue to our developers and they will investigate the best way to handle this to minimize confusion for our users.

Thanks for reporting this matter.

Geoff

The value is not really *used*, it is just copied around (right?).
So it *is* an instance of http://software.intel.com/en-us/forums/showthread.php?t=68849?
Yes?

Quoting - kcc

The value is not really *used*, it is just copied around (right?).
So it *is* an instance of http://software.intel.com/en-us/forums/showthread.php?t=68849?
Yes?

Without taking the time to once again delve into themany rings of wrapper scripts from the implementation of STL involved, I really can't say how -- or which --value is being used. From a glance at the names of the symbols involved here, though, I think it would be fair to agree that a value is being moved around.

As for the other thread, yes, there are many similarities. Intel Parallel Inspector is correctly finding a memoryerrorhere which, however,isbenign -- as in the other thread. And I have opened an issue with the developers which is under investigation as I write this -- as in the other thread. We sincerelyappreciate you bringing this to our attention.As Vladimir wrote in the other thread, "This is the intention to report error (not warning) on the level mi4. You can suppress them easily. What exactly is bad?"

Geoff

I don't agree that this is a benign error; imho this is not an error at all.
Anyway, what about this test:

c:Userskcccxxtest2>type test.cpp
#include
int main() {
std::priority_queue *Q =
new std::priority_queue;
Q->push(1);
delete Q;
}
c:Userskcccxxtest2>cl /Zi /EHsc test.cpp
Microsoft 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

test.cpp
Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
/debug
test.obj

c:Userskcccxxtest2>test.exe

c:Userskcccxxtest2>"C:Program Files (x86)IntelParallel StudioInspectorb
in32"insp-cl.exe -collect mi4 test.exe

c:Userskcccxxtest2>type r000mi4insp-cl.txt

=== Start: [2009/10/29 13:55:54] ===
Used suppression file(s): []
1 new problem(s) found
1 Uninitialized memory access problem(s) detected
=== End: [2009/10/29 13:56:03] ===

------------------ report: -----------------

Read:

test.exe!push
queue:212
test.exe!main
test.cpp:5

Allocation site:
test.exe!main
test.cpp:4

------------------ end report -----------------

Most likely, the problem is the same as intopic/68849

As for 'You can suppress them easily'. Sorry, but this is a myth.
You can easily suppress 1 or 10 such warnings.
But when you have thousands of false reports everywhere in the program due to a design flaw in the tool -- no way.

BTW, I am not inventing these tests, I simply take them from Chromium's base_unittests.
http://dev.chromium.org/developers/how-tos/build-instructions-windows

Thank you for the additional information. We will use it in improving our product.

Geoff

As for 'You can suppress them easily'. Sorry, but this is a myth.
You can easily suppress 1 or 10 such warnings.
But when you have thousands of false reports everywhere in the program due to a design flaw in the tool -- no way.

Yeah.. I had to agree in that thread that this problem is not so easy to suppress - this could be annoying.

Leave a Comment

Please sign in to add a comment. Not a member? Join today