• The same user cannot run simultaneous remote Call Graph activities on a single vtserver session. [SCR #23894]
  
  
• If you are upgrading your version of the Intel® VTune™ Perforane Analyzer, after installation you may discover it is not possible to create a call graph project. To correct this issue, remove the /tmp/vtune_username/ directory, which ensures that the files in it were not created by an older version of the VTune analyzer.
  
  
• The LD_LIBRARY_PATH environment variable must not contain /lib. Including /lib in the LD_LIBRARY_PATH environment variable may cause call graph to load the wrong shared object with the application. [SCR #19374]
  
  
• The LD_LIBRARY_PATH environment variable must always contain an absolute path, not a relative path or Call Graph may fail to profile the application. [SCR #24322]
  
  
• Two options are available for launching the application: direct execution, and by using an application launcher. When using an application launcher, make sure to do the following:
  • Define the -moi parameter.
  • This loader capability does not support running user setuid applications.
  • The launcher application may alter the running environment of the application. Therefore, the module information in the property page for vtl, or the Advanced Activity Configuration dialog box for GUI users, may change during the Activity run.
  • If the profiled application uses the LD_PRELOAD env variable, the VTune analyzer saves and concatenates the profiled application value after the VTune analyzer value. The original value is restored after completing the Activity.
  
  
• Call graph support is based on binary instrumentation, and therefore only instrumented functions are reported in the call graph results. There can be several reasons why a function may not be instrumented:
  • There is no symbol to the function in the binary (the image is stripped).
  • The first basic block of the function is smaller than five (5) bytes.
  • The function is inline and therefore doesn't exist in the binary.
  
  
• When an instrumented application calls the exec() system call, the whole image context is replaced with the new image. If the application calls exec() with the original name of the instrumented image, then the instrumented image is used. If the application calls executables that are not in the list of modules of interest, the original (non-instrumented) image is called, and no results are generated from this point in the run.
  
  
• Setuid images are not supported by call graph. The setuid mechanism is used to give a user process the effective user ID of another user, usually root. You can use call graph and run the setuid executable only if you are logged in as the same user as the owner of the setuid executable. [SCR #13308]
  
  
• Call graph results are written during the regular termination procedure of the process. This means that if the process did not terminate normally, no call graph results are generated. The application may terminate abnormally due to the following reasons:
  • Some type of crash (such as an access violation) occurred during the termination procedure.
  • The application caught an unhandled termination signal.
  
  
• To generate call graph results in the above cases, you need to cause a proper termination before it is improperly terminated by itself. Use one of the following methods:
  • Use the ActivityController command line to stop the Activity, which also stops the application.
  • Send a special signal to the instrumented application. The number of the signal should be the _Bistro_Exit_Signal_ environment variable. By default, the SIGUSR2 environment variable is used.
  
  
• Call graph uses SIGUSR2 as a special signal to produce results when the application terminates abnormally (except for Java applications). If your application uses this signal, please direct the Bistro_Exit_Signal_environment variable to another unused signal (SIGUSR1 for example).
  
  
• Statically linked executables are not fully supported. You may see problems, especially when C++ exception handling is used. To avoid this problem, dynamically link your application for call graph profiling.
  
  
• Call graph implements the same search algorithm as the standard loader for locating executables and shared objects. Therefore, if you use a private version of the loader with a different search algorithm, call graph may not find the required files.
  
  
• For IA-32 processors, the call graph information of an application is kept in memory during the run. By default, the call graph memory buffer limit is half of the physical RAM. If your application is using a large amount of memory, this can cause an extreme slowdown. To overcome this slowdown, reduce the size of the memory buffer used for call graph. The size of the buffer is defined in the property pages in the .ini file. Setting other value to the buffer size can be done on the property pages through the command line tool or in Eclipse.
  To set the value in Eclipse, go to: Window » Preferences » VTune Performance Tools » Call Graph » Collector and set the Limit collection buffer size to option to the preferred number of KB.
  
  
• For Intel® Itanium® architecture processors, when your application exceeds the maximum RAM it does not dump the memory to a file, as described in the previous bullet. Therefore, when profiling on these processors, you need to make sure that you have enough swap space in order to complete data collection [SCR #21908].
  
  
• The buffer-size property name is buffer size. By default, the buffer size is set to 128MB, unless your system has less then 256MB, in this case, it is half of the physical memory. More information on the configuration file can be found in the VTune analyzer command line interface User's guide. By default, the VTune analyzer User's Guide is located in /opt/intel/vtune/doc/users_guide/index.htm.
  
  
• Call graph does not support applications that use two different shared objects with the same name, even if they are located in different directories. This may cause an abnormal termination of the VTune analyzer. [SCR #14986]
  
  
• Call graph supports the POSIX* threading methodology (either NPTL or linuxthreads). If your application uses the clone system call directly, it is bypassing POSIX* threads. All non-POSIX* multithreading environments and direct use of clone system calls are not supported. [SCR #13552]
  
  
• Call graph adds the pthreads library to the instrumented application in order to profile it. Call graph profiling does not support applications that cannot link to the pthread library into the executable. [SCR # 20583]
  
  
• Call graph measures Wait Time values using a heuristic model rather than absolute calculations. Because of this, Wait Time values should be considered as approximations only, not as quantitative results. [SCR #14526]
  
  
• The overhead of call graph data collection can be reduced by changing call graph runtime settings. The overhead varies depending on application characteristics. For example, applications with many small functions run slower. Refer to the man callgraph man page, or the integrated Eclipse platform help on the VTune analyzer, for more information on call graph.
  
  
• Using Function selection with a remote call graph Activity before running the Activity cause instabilities in the Eclipse GUI. To avoid this issue, run the Activity before using this functionality. [SCR# 20191]
  
  
• 32bit and 64bit Call Graph Java profiling may not work if the application is started from a script on Intel® EM64T systems. [SCR #24560, #25229]
  
  
• In Call Graph view, when trying to sort by a hierarchical column, the grid's behavior is to sort by the internal column, and not the hierarchical one - in this case simply set hierarchy off, sort by needed column, and set hierarchy on again. [SCR #23082]
  
  
• If you use the same short <name> for your application to profile and the module of interest, but the application and module of interest are in different directories, the VTune analyzer will give you an error message: <name> is not a valid module. If you are profiling on an IA-32 system, you will get the error message, but data collection completes successfully. On Intel® EM64T systems, the data collection will fail. An example command that will create this situation is: vtl activity -c callgraph -app /tmp/ls -moi /bin/ls. [SCR #25145]

This applies to:

Intel® VTune™ Performance Analyzer 8.0 for Linux*