Documentation
Rate This Document
Findability
Accuracy
Completeness
Readability
SubmitClose

Viewing a Multi-process Report

During the dynamic memory consistency check on a multi-process application, the final result report filters out system libraries (such as .so files), and some data race information may be missing. For further confirmation, you can go to the mp_report_Timestamp folder in the directory where the DevKit CLI Affinity Analyzer (advisor) is located and view the original memtracer_mp_report information.

For example:

==================
race detected: WRITE after READ
shared memory type: POSIX
resource: /dev/shm/myposixshm (shared memory file)
var address=0x0
 
1) READ pid=2421880, tid=2421880 [unknown]
       bt#0 offset=0x94ad0 function: strnlen module: /usr/lib64/libc.so.6
              source: [unknown]
       bt#1 offset=0x94e34 function: strncpy module: /usr/lib64/libc.so.6
              source: [unknown]
       bt#2 offset=0xfc30 function: __tls_get_addr module: /usr/lib/ld-linux-aarch64.so.1
              source: [unknown]
       bt#3 offset=0x400ee8 function: main module: /home/testdemo/memtracer_multiprocess_demo/multiprocess_demo/child_child/no_sync/posix
              source: /home/testdemo/memtracer_multiprocess_demo/multiprocess_demo/child_child/no_sync/posix.c:88
 
CONFLICTS WITH
2) WRITE pid=2421879, tid=2421879 [unknown]
       bt#0 offset=0x77238 function: vscanf module: /usr/lib64/libc.so.6
              source: [unknown]
       bt#1 offset=0x52c90 function: snprintf module: /usr/lib64/libc.so.6
              source: [unknown]
       bt#2 offset=0xfc30 function: __tls_get_addr module: /usr/lib/ld-linux-aarch64.so.1
              source: [unknown]
       bt#3 offset=0x400dc0 function: main module: /home/testdemo/memtracer_multiprocess_demo/multiprocess_demo/child_child/no_sync/posix
              source: /home/testdemo/memtracer_multiprocess_demo/multiprocess_demo/child_child/no_sync/posix.c:60

The report contains the following content:

  • race detected: race type
    • WRITE after READ: race scenario in which write operations are performed after read operations
    • READ after WRITE: race scenario in which read operations are performed after write operations
    • WRITE after WRITE: race scenario in which a write operation is performed after a write operation
  • shared memory type: type of shared memory resources (for example POSIX) where the race occurs
  • resource: path to the shared memory file where the race occurs, for example, /dev/shm/myposixshm
  • var address: address of the memory where the race occurs (specifically, the start position of the shared memory)

About the race access subjects:

The report body lists the details about two race accesses to the same memory address. Each access record contains the following information:

  • Operation type: indicates whether the access behavior is READ or WRITE.
  • Process and thread IDs: display the process ID and thread ID of the operation.
  • Call stack: displays the code execution path from bottom to top, including three major dimensions:
    • function: name of the function corresponding to the access
    • module: path to the library file or executable file where the function is located
    • source: source file and line number of the function

In the previous example file, lines 60 88 in the posix.c file have race access to the same address. You need to check the two lines of source code to see whether there is a process conflict.

Parent topic: Common Operations