Problems with Data Races Analysis

[libor_jendele]

Hello,

I 'm evaluating Intel Inspector before possibly buying it but up to now I am not successful. 

I have a fairly large project (mixed MS C++, Intel Fortran) under VS2013 using OpenMP multithreading. When trying Deadlock and Data Races Analysis I get warning: Inspector does not support the Microsoft OpenMP runtime module .... Where can I get compatible OpenMP modules and how to force their use within my C++ MS project? (I have installed MSVS2012 and Intel Fortran compiler XE). Can I use Intel inspector to inspect VS2012 C++ project?

When ignoring the above warning and test my executable (for data races), first it loads fine and then it suddenly stops. In the Collector Message windows I see "Loaded module: C:\AtenaV6\Projects\DLLs\Win32Debug\CCElements_2D_Basic.DLL.
Application exit code: -1 "

where CCElements_2D_Basic.DLL is the first DLL being loaded directly by AfxLoadLibrary(dll_name) from my code. If the tested app runs from VS2012 or is launched directly (command line), it executes well, i.e. CCElements_2D_Basic.DLL is built OK and loaded  successfuly. It even loads and executes well when launched from the Inspector for Memory leaks analysis. Is there any help to success also with Data races analysis, which is the most important analysis for me?
Note that if my app is called from batch, (i.e. I inspect a batch that in turns execute my app), then my app executes correctly, but the Inspector doe not find any problems in spite of the fact that data race conditions evidently occuer.

Can anybody help? Is the Inspector usable at all for testing larger solution built within MSVC2012 (mostly compiled by MS C++ compiler)?

Thanks for help Libor

PS. My solution is unfortunately so large that I can not upload it.

[SergeyKostrov]

>>... Where can I get compatible OpenMP modules and how to force their use within my C++ MS project?.. An ideal solution is to re-compile your sources with Intel C++ compiler and in that case version of OpenMP DLL implemented by Intel will be used. OpenMP DLLs implemented by Intel and Microsoft are compatible when it comes to OpenMP version 2.0 Standard. Binaries are absolutely Not compatible and OpenMP DLLs can not be substituted. Also, take into account that Microsoft has "frozen" OpenMP at version 2.0. At the same time Intel supports, and is going to support, all OpenMP standards and, of course, including 4.0. >>...When ignoring the above warning and test my executable (for data races), first it loads fine and then it suddenly stops... I don't know how to help here. It looks for me too project specific. It is Not clear what could be wrong with a call to AfxLoadLibrary MFC function and I wouldn't blame it in the first place. Did you try to create small test-cases for software subsystems used in your very large application? In that case investigations could be significantly simplified because a test will be done for a small portion of C/C++/Fortran codes.

[Peter_W_Intel]

>> If the tested app runs from VS2012 or is launched directly (command line), it executes well, i.e. CCElements_2D_Basic.DLL is built OK and loaded  successfuly.

Did you mean that the problem occurred when working on Inspector standalone application? If this is the case, try your app (or batch file) first in cmd prompt (ensure it works), then run "inspxe-vars.bat", finally run "inspxe-gui.exe". This is to inherit all environment requirements your app needs, in inspector GUI.

>> ...then my app executes correctly, but the Inspector doe not find any problems in spite of the fact that data race conditions evidently occuer.

You need to add interest of modules into Inspector project's properties\Target\Advances\Modules, if you launched batch file.

If you works in command line of inspector: do below (for example)

inspxe-cl -collect mi2 -executable-of-interest module-name -- my.bat 

[libor_jendele]

Thanks for your help.

To Sergey:

You are probably right that using Intel C++ may solve my problem. However, I'm afraid that many more (new ones) arise, if I switch to the Intel compilers, particularly in class/function templates, MFC engine and GUI, combining manage/native code etc. To me it looks like Intel can maintain only simple small project. It does not apply to compilers but it applies to all the rest. I have already some experiencewith VTune, Amplifier and now with Inspector. Often it is the same story. If I have 5 lines console app, all works fine. If I have a solution with 10000 files and 30  projects (dlls),  it fails to work. The Inspector reports false memory leaks, (MFC or AqTime e.g. does not report anything), VTune does not meassure functions from extra loaded dlls, (AqTime does)... I'm already afraid to move my whole solution to Intel environment. I'm sorry. The data race and deadlock analysis would be very helpful to me... (if it really works!!)

 To Peter:

My solution works under these conditions:
Start target.exe from command line.
Start bat that start target exe from command line.
Start target exe from VS2012 (both Run and Debug).
Start target exe from the standalone Inspector for memory leak analysis, (executes well, but reports false leaks).
Start target exe from VS2012 extension for the standalone Inspector for memory leak analysis, (executes well, but reports false leaks).
Start target bat from the standalone Inspector for data races and deadlocks. From that bat start target exe. It executes well but it finds no problem (although for sure I have a few data race conditions present).  

It doesn't work (i.e. fails to load one of my dll loaded directly by AfxLoadLibrary(dll_name) in the cases listed below. That library is not loaded during loading ..exe, but it is loaded lated from one of my C++ function) and it looks like the problem occuer during its instrumentation, (which by the way take about 30sec time; the loading itself without instrumentation takes typically 1-2sec):
Start target exe from the standalone Inspector for data races and deadlocks.
Start target exe from VS2012 extension for the standalone Inspector for data races and deadlocks.

It does not matter, if I include or exclude the problematic dll from modules to be inspected. It always fail to load it and exit with RC -1. Strange, isn't it. Looks like Include/Exclude modulse are there just for fun.

The same behaviour is for debug and relase version. The release version is optimized but retain debug information, (/Zi).

I really need a tool to detect data race conditions in my solution. I'l be very grateful, if someone can suggest, what to set somewhere to avoid the specified bug in teh Inspector.

And may I ask once again: Does the Inspector really cooperate with MS C++ or it is tuned and debugged for Intel compilers only? Did anybody try it for a large solution?

Thanks. Libor

[SergeyKostrov]

>>To me it looks like Intel can maintain only simple small project... You have a project organization issues and problems. This is because your project was Not designed and implemented to be easily portable. >>...If I have 5 lines console app, all works fine. If I have a solution with 10000 files and 30 projects (dlls), >>it fails to work... Intel C++ compiler is Not designed for just small projects. It is designed to handle anything! For example, these are exact numbers I have: Number of solutions: 5 Number of projects: 76 Number of configurations ( 16-bit, 32-bit, 64-bit, Mobile ): 148 Number of C/C++ code lines for test cases only: more than 50,000 Number of supported C/C++ compilers: 5 ( excluding different versions / supported brands: Intel, Microsoft, MinGW, Borland C++, Turbo C++ / if I count versions it will be ~10 ) >>..I'm already afraid to move my whole solution to Intel environment. I'm sorry... If the project is large it could take from a couple of weeks to a couple of months to complete the integration of Intel C++ compiler. I gave you real numbers and it is up to you to decide what to do next. My opinion is: if there a task and budget then it makes sence.

[Mark_D_Intel]

You can link with the Intel OpenMP library while using the MS compiler.

Documentation page is here:

http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-win/hh_goto.htm#GUID-0E85F327-A19E-410C-8203-0A89C8F32635.htm

[libor_jendele]

Thank you all for your help.... Libor

[SergeyKostrov]

>>You can link with the Intel OpenMP library while using the MS compiler. >> >>Documentation page is here: >> >>http://software.intel.com/sites/products/documentation/doclib/stdxe/2013 Thanks Mark for that link. I tried to do similar some time in 2012 and I had a manifest related runtime error.

[Peter_W_Intel]

> It doesn't work (i.e. fails to load one of my dll loaded directly by AfxLoadLibrary(dll_name) in the cases listed below. That library is not loaded during loading ..exe, but it is loaded lated from one of my C++ function) and it looks like the problem occuer during its instrumentation...

Is it possible that instrumented AfxLoadLibrary failed to load your instrumented dll? You may exclude AfxLoadLibrary to see if it can load your instrumented dll?

> The same behaviour is for debug and relase version. The release version is optimized but retain debug information, (/Zi).

Probably you need to check more - Compiler option "/MDd", LINK options "/FIXED:NO" and  "/DEBUG" they were enabled?

 It's better to submit problematical dll with simple call tester to Intel Premier for investigating.

[AndrewC]

In defence of Inspector XE 2013 and Amplifier XE 2013 I use these on large, complex, threaded (OpenMP + boost::thread) MFC projects with great sucess. It is very easy to make source code compatible with both Intel and the Microsoft (Studio 2010) compilers.