What ITT export functions you used?
Even you inserted ITT APIs in code, without VTune - it can run. I suspect if you used Resume API first in code if you added "-start-paused" option in CLI. Another concern is if you used APIs in parallel code to cause logic in correct? Please consider use it in serial code (Resume API) --> parallel code -> serial code (Pause API after fork-join), for example.
Is it possible that you can provide a simple reproducer?
We are using
__itt_suppress_push(code) __itt_suppress_pop() __itt_sync_create(addr, objtype, name, attribute) __itt_sync_destroy(addr) __itt_sync_cancel(addr) __itt_sync_prepare(addr) __itt_sync_acquired(addr) __itt_sync_releasing(addr)
these functions in a special "profile" build to silence false data races reported by Intel Inspector. These ITT functions are removed from our deployable release build. Thus we have been able to VTune our release build. However we recently added TBB and VTune is now causing the release build of our app to crash in same manner we observed with our profile build before the addition of TBB.
I'm using the VTune and Inspector from the Parallel Studio XE 2016 Update 2 suite (note Update 1 has the same issue).
I have first tried linking to
C:\Program Files (x86)\IntelSWTools\Inspector XE 2016\lib64\libittnotify.lib
C:\Program Files (x86)\IntelSWTools\VTune Amplifier XE 2016\lib64\libittnotify.lib
but my apps still crashes when profiled from VTune.
I assume it shouldn't matter which .lib I choose? Though I do see that VTune's version is bigger so I assume it contains additional functions?
What you listed API (such as_itt_suppress_push(code), _itt_suppress_pop)...are not for VTune(TM) Amplifier, your linking libittnotify.lib from VTune will cause unexpected result. You can check VTune's online helper to double-check.
My opinions are: 1) Use "#ifdef " to exclude Inspector's APIs in code - build binary to run VTune. 2) also exclude VTune's APIs in code - build binary to run Inspector. 3) Link to different library (libittnotify.lib) for different purpose.
1. Even if I remove all ITT from my app, profiling with VTune will still cause my app to crash if I use the prebuilt TBB Window binaries downloaded from https://www.threadingbuildingblocks.org which contain IITT functions by default. This indicates there's a bug somewhere, either in VTune or my machine setup.
2. It seems very inconvenient to me that we can't use the same ITT functions for both VTune and Inspector? Is this correct?
It is so interesting that your application with TBB doesn't work with VTune Amplifier, without ITT use.
Is it possible that you can provide a simple reproducer? What is TBB version you used? It seemed that you used (downloaded) it from open source/binary, can you try latest TBB in Intel Register Center Download Site to repeat this? What are VTune CLI you used?
I experienced a similar old issue from other, who used Intel C++ Composer, TBB but never use ITT, but VTune detected ITT function. The problem has been fixed - if user uses latest Composer, TBB and VTune Amplifier.
You can use anything available in ITT API - there should not be any issue with that profiling under VTune - the product will handle only those ITT functions that it knows (relevant for both VTune and Inspector).
In which cases your app does not crash under profiling? Which analysis types did you try? Does it crash with Basic Hotspots or Advanced Hotspots (no stacks) with "Analyze user tasks" turned off?
Also, can you see the stack of your app crash? Is there any VTune module in the stack?
Mysteriously our app, with ITT functions included, is no longer crashing when profiled with VTune. This is not yet confirmed but we suspect that some subtle bug in the apps startup code was only uncovered when profiled by VTune so believe this issues is now resolved.
For the record, it was crashing with Basic Hotspots and Advanced Hotspots (no stacks) where "Analyze user tasks" was turned off.
Thanks for response Scott, good to know!
Well, VTune affects application execution. If there are e.g. data races in the application, the negative effect may happen more (or less) often under profiling as the timing of some functions may change insensibly.