Importing Memory Analysis data

You can import Memory Analysis sessions from XML files generated by the IDE or import logs written by the librcheck library as an application ran.

Typically, XML files containing session data are already on the host machine, because you obtain them from either the IDE or other team members who share analysis results. If you run an application from a command line that loads librcheck and redirects the event and trace output to a file, you can copy over the log file to the host by using the Target File System Navigator.
To import Memory Analysis data:
  1. Select File > Import > QNX > Memory Analysis Data, then click Next.
    Alternatively, if the Analysis Sessions view is open, you can right-click anywhere in it and choose Import Session, select Memory Analysis Data from the wizard list, then click Next.
  2. In the Input File field in the Import window, specify the file containing the data that you're importing.

    You can enter an absolute host path or click Browse to open a popup window that lets you choose a file from the workspace or local filesystem, using a file selector. When naming the file, you can use ${workspace_loc:*} to specify the current workspace; for example: ${workspace_loc:project_name/results_file}.

    The filename must end with an .xml or .rmat extension. When importing logs (.rmat files), you must pick a session for storing the data and optionally, specify the paths of the binary files, by following the next three steps. For XML files, skip to StepĀ 6.

  3. Select a session for storing the log data.
    In this window, the Memory Analysis sessions are listed from oldest (at the top) to newest (at the bottom), with checkboxes that let you select just one session. Note that the session you select must open, as indicated by the open session icon (Icon: Open Memory Analysis session). There's also a Create New Session button, if you want to store the log in its own session.
  4. Optional: Click Next to proceed to the Binary Path window, then specify the executable binary and any shared libraries that ran during the analysis sesssion.

    To see line numbers in the event data (including the stack traces), you must have copies of the executable binary and library files with debug symbols on your host machine, so the IDE can associate the events with call sequences.

    Next to the Select executable file text field, you can click Browse to open a popup window that lets you choose a workspace or local filesystem directory. The text field gets populated when you make your selection, for example: ${workspace_loc:HelloWorld/build/x86-debug/HelloEarth}

    The Libraries Search Path panel lists the paths that the IDE should search to find shared libraries referenced by memory event data. This UI control behaves the same way as the Libraries tab in the launch configuration.

  5. Optional: Specify the source code paths.
    The Source Lookup Path panel lists the paths that the IDE should search to find source code that's related to memory events but wasn't compiled on the host. This UI control behaves like the Source tab in the launch configuration, meaning you don't need to define these paths if your source code was built on the host. The difference is that you can enable recursive directory searching, by checking the boxes in the Recurse column.
  6. Click Finish.

    The IDE begins importing the data.

    If you're importing a session from an XML file or you chose to create a session for storing an imported log, you'll see a new entry in Analysis Sessions. The session header begins with the imported: string but then follows the usual naming convention while using a new, unique session number. You can rename the session by right-clicking its entry and choosing Rename.

    If you're importing a log into an existing session, you'll see a new process entry in that session.

When the import operation finishes, you can view the results from the earlier analysis session. The Memory Analysis reference explains how to interpret the results.