When the program terminates Intel® Trace Collector prints a list of all unfreed MPI requests together with their status. Unfreed requests are usually currently active and application should have checked their status before terminating. Persistent requests can also be passive and need to be freed explicitly with

MPI_Request_free()

.

Not freeing requests blocks resources inside the MPI and can cause application failures. Each time the total number of active requests or inactive persistent requests exceeds another multiple of the

CHECK-MAX-REQUESTS

threshold (that is, after 100, 200, 300, . . . requests) a

LOCAL:REQUEST:NOT_FREED

warning is printed with a summary of the most frequent calls where those requests were created. The number of calls is configured through

CHECK-LEAK-REPORT-SIZE

.

Finalizing the application with pending requests is not an error according to the MPI standard, but is not a good practice and can potentially mask real problems. Therefore a request leak report will be always generated during finalize if at least one request was not freed.

If there are pending receives the check for pending incoming messages is disabled because some or all of them might match with the pending receives.

Active requests that were explicitly deleted with

MPI_Request_free()

will show up in another leak report if they have not completed by the time when the application terminates. Most likely this is due to not having a matching send or receive elsewhere in the application, but it might also be caused by posting and deleting a request and then terminating without giving it sufficient time to complete.

The MPI standard recommends that receive requests are not freed before they have completed. Otherwise it is impossible to determine whether the receive buffer can be read. Although not strictly marked an error in the standard, a

LOCAL:REQUEST:PREMATURE_FREE

warning is reported if the application frees such a request prematurely. For send requests the standard describes a method how the application can determine that it is safe to reuse the buffer, thus this is not reported as an error. In both cases actually deleting the request is deferred in a way which is transparent to the application: at the exit from all MPI calls which communicate with other processes Intel® Trace Collector will check whether any of them has completed and then execute the normal checking that it does at completion of a request (

LOCAL:MEMORY:ILLEGAL_MODIFICATION

) and also keep track of the ownership of the memory (

LOCAL:MEMORY:OVERLAP

).

In addition not freeing a request or freeing it too early, persistent requests also require that calls follow a certain sequence: create the request, start it and check for completion (can be repeated multiple times), delete the request. Starting a request while it is still active is an error which is reported as

LOCAL:REQUEST:ILLEGAL_CALL

. Checking for completion of an inactive persistent request on the other hand is not an error.