Memory Leak Analysis

Prerequisites

• If the --events parameter needs to be set when the memory analysis function is used, ensure that the --events parameter contains alloc and free.
• Do not set the --steps parameter when using the memory analysis function.

Online Mode

During memory analysis, the mstx instrumentation function is required for fault location. For details, see MindStudio mstx API Reference.

1. Run the user program using the msLeaks tool. Application is the user program.

   msleaks ${Application}

2. After the command is executed, the following two types of command output are displayed.
   1. If the command output like Figure 1 is displayed, a memory leak occurs. The command output displays the summary information about memory leaks of each ID, including the number of steps where memory leak occurs, associated kernel, address, and leak size.
      Figure 1 Memory leak
      
   2. If the command output like Figure 2 is displayed, the memory fluctuates. The command output displays the memory fluctuation in a single step (defined by the ratio of the minimum memory pool allocation to the maximum memory pool allocation) and the minimum memory pool allocation. The minimum ratio and maximum ratio are provided as references. Users can determine whether there is a memory leak risk based on the ratio.
      

      The memory is not stable in the first step. Therefore, only the memory fluctuation from the second step can be analyzed. The memory fluctuation in the first step can be ignored.

      Figure 2 Memory fluctuation
      
3. Use a visualization tool to display the json file (visualization memory information) in the output file, as shown in Figure 3. You can view the memory deallocation status. Memory problems are analyzed based on the memory information visualization diagram. For details about the visualization information, see Output Description.
   Figure 3 Memory deallocation status
   
4. Figure 4 shows the user's instrumentation information. When the time of a leaked memory allocation coincides with the time indicated by the arrow, it indicates that a memory leak has occurred in the code near the mstx instrumentation location.
   Figure 4 Instrumentation points
   

Offline Mode

msLeaks supports offline leak analysis of memory events in a specified range. After using mstx to mark the memory leak analysis range, you can use this function to analyze the dumped files.

Currently, the offline memory leak analysis function supports only HAL memory leak analysis.

• Tool deployment

  Before using msLeaks to perform offline memory leak analysis, install the open-form environment. For details, see CANN Software Installation Guide (Open-Form).

  1. After the open-form environment is successfully installed, start two remote login tools to log in to the host and device, respectively.
  2. Download the CANN toolkit and ops operator package of the required version by referring to the CANN Software Installation Guide, and decompress them.
  3. Upload the user test files and msLeaks tool on the host to the device according to the actual situation.

     The msLeaks tool package is stored in $HOME/Ascend/cann/tools/msleaks by default. Use the actual installation path.

     

     Before transferring files, enable the SSH service. After the file transfer is complete, disable the SSH service in a timely manner to ensure system security. For details about how to enable the SSH service, see "File System Customization" > "Modifying a File System" > Enabling the SSH Service in the CANN Software Installation Guide (Open-Form).

  4. Upload the ACL dependencies on the host to the device.

     The ACL dependencies are stored in the /usr/local/AscendMiniOs/acllib/lib64 directory on the host. Upload the dependencies to the /usr/local/AscendMiniOs/aarch64-linux/data directory on the device. The actual paths on the host and device may vary. Upload the dependencies according to the actual situation.

  5. Run the following command on the device to set the environment variable.

     export LD_LIBRARY_PATH=./lib:./lib64:./:./home/HwHiAiUser:$LD_LIBRARY_PATH;export ASCEND_OPP_PATH=./;

  6. On the device, check the missing so package.
     • Before running the user test file, run the following command on the device to check the missing so package: MyApplication is the user test file.

       ldd ${MyApplication}

     • If the command output like the following is displayed after the user test file is executed, the so package is missing on the device.

       1	libascend_xxx.so: cannot open shared object file: No such file or directory

  7. On the host, search for the missing so package. Most so packages are stored in $HOME/Ascend/cann/aarch64-linux/lib64/.

     You can also run the following command on the host to query the path of the missing so package: soName is the name of the so package.

     find / -name ${soName}

  8. Upload the so package on the host to the device. Upload the so package as required.
• Memory analysis
  1. Apply the mstx mark function to the range where leak detection is required. For details about mstx instrumentation, see MindStudio mstx API Reference.
     

     • The mark information is used as the input of the offline analysis interfaces.
     • Use the mark function to mark three points, which are referred to as A, B, and C. The memory allocated within the range from A to B must be deallocated before point C. Otherwise, the memory is considered as a memory leak.
  2. Run the following command to use the msLeaks tool to run the user program and obtain the dumped .csv file. Application is the user program.

     msleaks ${Application}

  3. Run the following command to call the Python interfaces to perform offline leak analysis on the output .csv file:

     1 2	import msleaks msleaks.check_leaks(input_path="user/leaks.csv",mstx_info="test",start_index=0)

     The parameters are as follows:

     • input_path: path of the .csv file. The absolute path is required.
     • mstx_info: mstx text information used for mark instrumentation, which is used to mark the range of leak analysis.
     • start_index: ID of the instrumentation location where the memory leak analysis starts, that is, the sequence number of the mstx instrumentation location that meets the analysis conditions.
     If the command output like Figure 5 is displayed, a memory leak occurs.

     Figure 5 Offline leak analysis