Using the tool

Since you must repeat the given use cases many times to detect resource leakage, it is best to automate the running of the test cases. Enter the following commands both before the first test case and after each additional test case:

This creates a directory called <use-case-name> (if it does not exist) and adds on each invocation a new subdirectory with the current endurance data. The subdirectories are named 101, 102, and so on.

Since syslogs can be large and they are included in the endurance data, it is best to clear syslogs (as indicated above) after the endurance data is stored. Otherwise storing the data can take quite a long time and (if you take lots of measurements) consume huge amounts of disk space.

Checking X resource usage

Endurance data contains the xmeminfo tool output, but if you are only interested in the X resource usage details, you can also use it directly.

To get all X resource names and their usage for all X clients, enter the following command:

$ xmeminfo

To check specific X resource for a single X client, enter the following commands:

Note: If you run this as a root and not within a user session, it is possible to get an error message that xmeminfo cannot connect to the X server. This is caused by an incorrect DISPLAY set. In that case, set DISPLAY before. Enter the following command:

# export DISPLAY=:0

The save-incremental-endurance-stats script sets this automatically if it is missing because the information provided by xmeminfo is required by the post-processing tools.

Emphasising leakage

Sometimes it is not clear from the endurance data whether there is a memory leak. Increasing the number of test case runs helps, but getting more measurements does not necessarily make it easier to see the leakage. In this case, it is best to emphasise the leakage by increasing the number of test case repeats between measurements exponentially, like this:

Note: the process which use case is automated, must not exit between the repeats. If so, the collected data is useless because resource usage differences are shown per process.

Post-processing

After the tests have been completed, transfer the endurance data to the host workstation and use sp-endurance-postproc for post-processing. Note that the post-processing tools create the error and resource leakage summary from the differences between the second and the last measurements. They assume that:

The first measurement is the initial state, that is, the system and application are still in a state where things required by the test case have not been initialised yet.

Processes involved in the test case have not been terminated before the last measurement. If the process does not exist anymore in the last measurement, there is nothing to differentiate.

To obtain a rough system memory overview of the endurance data on the device, enter the following command: