We have introduced aio to our codebase, but vtune silently exits when encountering this function. Other tools, such as gdb and valgrind runs this code fine.
The version used is update 4. (build 128765)
This is the command line we're running
/opt/intel/vtune_amplifier_xe_2011/bin64/amplxe-cl -user-data-dir ~/vtune -collect hotspots -duration 60 -- Release-Static-Linux-intel64/UniverseManager
Using result path `/home/anderse/vtune/r036hs'
Executing actions 50 % done
Error: Error 0x4000001d (Cannot find raw collector data) -- Cannot re-finalize the result: it has no raw collector data.
size_t IOFile::Read( void* buffer, uint64 startPos, size_t numBytes )
size_t numRead = 0;
fcAssert( buffer );
fcAssert( CanRead() );
if ( m_hFile )
request.aio_fildes = fileno(m_hFile);
request.aio_offset = (off64_t)startPos;
request.aio_buf = buffer;
request.aio_nbytes = numBytes;
request.aio_reqprio = 0;
request.aio_sigevent.sigev_notify = SIGEV_NONE;
aiocb64* requestPtr = &request;
if (aio_read64(&request) != 0)
else if (aio_suspend64(&requestPtr, 1, NULL) != 0) // vtune exits here
numRead = aio_return64(&request);
if we replace the above function with fread/fopen it does not silently exits.
There are various possible causes for the error. Before proceeding, can you attempt with Intel VTune Amplifier XE 2011 update 7? Then, can you verify that the Tachyon sample code can be analyzed in the same way as your application? This will help narrow the scope of probable causes. Is the application being ran as one user while analysis is ran as another user? If possible, run both as root and see if the behavior changes.
I have created a small testcase to narrov the scope
g++ vtune.cpp -lrt
/opt/intel/vtune_amplifier_xe_2011/bin64/amplxe-cl -user-data-dir ~/vtune -collect hotspots -- ./a.out
/opt/intel/vtune_amplifier_xe_2011/bin64/amplxe-cl -user-data-dir ~/vtune -collect hotspots -- /usr/sbin/lsof -i
Everything is beeing ran as my user.
I seem to have experienced similar behavior with aio and hotspots analysis. In my test, the analysis finished. However there were several warnings including Warning: Failed to stop the sampling timer for the thread and Warning: Cannot load data file `
I will bring this behavior to the attention of the Developers and update this public thread when new information is available. If you have a Premier Support account, you can if you wish, create a Premier Support case and the behavior can also be worked / tracked there.
I added substantial run time to the example app so now it runs for more than a short period of time. With this, the example runs without error in Update 7. The behavior has most likely changed between update 4 and the latest released version. Can you update to the latest (Currently Update 7) and attempt to replicate with your application and in your environment?