I did data collection on a linux host (using the -collect flag). Then I tried to run the analysis on another linux host. However, at this time amplifier was not able to find any of my shared libraries, and it did not even find itself (Cannot locate file /path/to/vtune/bin64/pinbin).
The two linux machines are identical: same hardware, same filesystems are mounted at the same locations, same OS runs on both. Only the hostname is different.
Any idea what could be amiss? Thanks for any help!
PS: I'm using amplifier in parallel_studio_xe_2018.1.038
We could observe the version of VTune you are using (2018.1.038) seems outdated. Could you please try using the latest version of VTune which is available for free. You can download VTune Profiler from any one of these sources:
- Standalone version
- As part of Intel® oneAPI Base Toolkit
- As part of the Intel® oneAPI System Bring-Up Toolkit
Once you have the latest version you can set up environment variables by following the below link. Please let me know in case if you are still facing these issues even with the latest version of VTune.
I have installed oneAPI and tried to analyze the report with that one. Same result :-(.
Note that the cluster where I'm running the data collection is rhel6, so I could run the collection only with the older version. I tried the analysis with the new vtune on an rhel7 machine (but the directory mounts are present on that machine, too; the files should have been found).
I have figured it out, and there are two issues with vtune:
- I ran vtune-gui through strace to find out what files it tries to open. It turns out that even though the files are recorded with explicit path (e.g., /path/to/my/shared/libs/foo.so), vtune searches for them everywhere except in that explicit path. Everywhere meaning:
take a bunch of default search paths (like /root/of/result/dir/sqlite-db/archive/binaries, /root/of/result/dir/archive/all, $HOME/intel/vtunesamples/matrix, and quite a few others), then take every subpath of the shared lib (like the full path, then /to/my/shared/libs/foo.so, then /my/shared/libs/foo.so, etc), and then create every possible combination (e.g., /root/of/result/dir/archive/all/my/shared/libs/foo.so).
But, as I said, the original absolute path is never considered.
- Then I tried to add / to the search path hoping that vtune will find //path/to/my/shared/libs/foo.so (the starting // is not nice, but it would work). Big mistake...
Apparently in this case vtune tries to prepend not only / to the path, but tries every directory under / ! That is, the whole filesystem. Imagine that in a corporate environment with hundreds/thousands of user home directories... This was bad enough, but it got worse
: I was not able to remove that search path. It was not in any project I tried to open, but whenever I opened a result directory, / was there in the search path and finalization started immediately (and cancel did not work -- I suppose the system was busy trying to open files), so I could not remove / from the search path. I think that a) the manually entered search path should not be added to every opened result dir automatically; and b) it should be possible to modify the search path without starting finalization. I was able to remove / from the search path only by removing $HOME/intel and $HOME/.intel (maybe one would have been enough)
The first item is definitely a bug, IMHO. The second... I can see the point behind the recursive search, but I still don't like it :-).
#1 - When working with a result collected on another host, VTune doesn't use absolute paths of binary files (hi chance to get a binary file with the same name but different version/content). The binary/symbol search paths should be specified in such cases. There should be a warning message about that in VTune finalization log.
I tried to reproduce the issue by profiling with the latest version of vtune and finalizing on a different machine. I was not able to reproduce the issue. The shared objects/files are being found without any issues.
Vtune searches for files in a particular order. You could find more information about the search order in the below link. Please make sure the symbol files are present in the the path that is referenced in the binary file, even in the RHEL7 machine. If not please add them to search directories.
If you need to add additional folders to be searched for symbols, you could add them to search paths either during profiling or during finalizing. The search is non-recursive as per documentation(We have verified this in latest version of vtune).
We suspect the issues might be due to the fact that you are profiling with 2018 u1 version of vtune, Could you please try profiling with the latest version of vtune and opening the results with the same version to see if you are still facing the issues.
Disclaimer: As you may have already noted RHEL6 is not an officially supported platform for the current vtune release thus it wouldn't be guaranteed to work , however you could give it a try.
We assume that your issue is resolved. If you need any further assistance, please post a new question as this thread will no longer be monitored by Intel.