Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Jonas_M_
Beginner
402 Views

"Invalid memory access" deteced when using std::map ?

Hi,

I use a std::map (from #include <map> ) in my Code (see minimal example below).

After compiling with the Intel Composer 2013 I analyzed my program with the Intel Inspector XE.  I got various "Invalid Memory Access" errors. The errors are located in "xmemory", which is not from me. The last line in my Code is a call to the std::map.

If I compile with the Mircosoft compiler, integrated in Visual Studio 2010, and analyzed my program the Intel Inspector  does not find any Error.

Question: Is that...

  1.  .. a problem in the code?
  2. ... a problem of the std::map implementation?
  3. .. just a false positive from the Inspector?

Please find attached a example Visual Studio (2010) project. Inclusive an Inspector result with the problems.

Compiler settings are default of Visual Studio (for Debug mode), but for x64 and with the Intel compiler.

My minimal code example: (copied from here)

[cpp]#include <string>
#include <iostream>
#include <map>
#include <utility>

using namespace std;

int main()
{
   map<string, int*> Employees;
   int a = 5234;
   int b = 3374;
   int c = 1923;
   int d = 7582;


   // Examples of assigning Map container contents

   // 1) Assignment using array index notation
   Employees["Mike C."] = &a;
   Employees["Charlie M."] = &b;

   // 2) Assignment using member function insert() and STL pair
   Employees.insert(std::pair<string,int*>("David D.",&c)); //makes 3 "Invalid memory access"
 
   // 3) Assignment using member function insert() and "value_type()"
   Employees.insert(map<string,int*>::value_type("John A.",&d));

   // 4) Assignment using member function insert() and "make_pair()"
   Employees.insert(std::pair<string, int*>("Peter Q.",&d));

   cout << "Map size: " << Employees.size() << endl;

   for( map<string, int*>::iterator ii=Employees.begin(); ii!=Employees.end(); ++ii)
   {
       cout << (*ii).first << ": " << *(*ii).second << endl;
   }
}
[/cpp]

Platform/Tools:

  • Windows 7
  • Visual Studio 2010
  • Intel® C++ Composer XE 2013 Update 5 Integration for Microsoft* Visual Studio* 2010
  • Intel® Inspector XE 2013 Update 6, (build 283349)
0 Kudos
5 Replies
Mark_D_Intel
Employee
402 Views

I can reproduce it, and will look into it further (these are false positives from IXE).

There is an unrelated issue in the project settings. Under Properties->C/C++->Code Generation, the "Basic Runtime Checks" should be turned off (set to "Default").   In particular, the stack frames check (/RTCs) will initialize the stack to some non-zero value, and IXE will then consider the stack to be initialized.   With this property change, IXE is able to find uninitialized accesses introduced into the example (for instance, change "int a = 5234;" to "int a;")

Jonas_M_
Beginner
402 Views

Thanks for your answer and explanation.

I think the point with the project settings is not unrelated. With turned off "Basic Runtime Checks" I get no errors shown anymore by the Inspector.

SergeyKostrov
Valued Contributor II
402 Views

I could not reproduce the problem when Default compiler options were used: [ Debug ] ..\Tests>icl.exe /MDd Test035.cpp ... ..\Tests>Test035.exe Map size: 5 Charlie M.: 3374 David D.: 1923 John A.: 7582 Mike C.: 5234 Peter Q.: 7582 [ Release ] ..\Tests>icl.exe /MD Test035.cpp ... ..\Tests>Test035.exe Map size: 5 Charlie M.: 3374 David D.: 1923 John A.: 7582 Mike C.: 5234 Peter Q.: 7582
Jonas_M_
Beginner
402 Views

Sergey your are showing the output of program. But the output of the program was not the problem. The output was always correct.

The problem was the output of the Intel Inspector Tool. The Inspector had detected some "Invalid Memory Access" inside a file called "xmemory" which is releated to the std::map.

SergeyKostrov
Valued Contributor II
402 Views

>>Question: Is that... >> >>1. .. a problem in the code? The test case looks right. >>2.... a problem of the std::map implementation? This is a long story and compiler warnings related to xmemory header file first time were reported in 1998 ( by Microsoft Visual C++ version 6 ). >>3... just a false positive from the Inspector? Try to use VS Debugger to verify that nothing is wrong with the "suspected" codes when compiled with Intel C++ compiler.
Reply