You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The project is split into `instrument.c` which only contains purely technical (memory instrumentation, fn wrapping..) DynamorRIO api setup/config and `race_detector.c` which contains the race detector implementation described in[this](https://storage.googleapis.com/pub-tools-public-publication-data/pdf/35604.pdf) paper.
4
-
This project is a simplified but accurate representation of the, in section 4.3, described "precise, slow" detection mode.
3
+
The project is split into `instrument.c` which only contains purely technical (memory instrumentation, fn wrapping..) DynamorRIO api setup/config and `race_detector.c` which contains the race detector implementation. The race detector is based on[this](https://storage.googleapis.com/pub-tools-public-publication-data/pdf/35604.pdf) paper.
4
+
This project is a simplified but accurate representation of the in section 4.3, described "precise, slow" detection mode.
5
5
All events are "exported" in instrument.h and implemented by race_detector.c (fed to DynamoRIO by `instrument.c`).
6
-
7
6
The detector is fully build on a clock-vector before/after relations mechanism to detect races.
8
7
8
+
## Practicability
9
+
10
+
The project is able to detect basic write-write and write-read data races. Since DynamoRIO isn't super stable in multithreaded environments, the results can vary, so it's good practice to check the sets on potential differences(although there were no changes done to the checked program) if reproducibility is required.
11
+
9
12
## Clock Vector Based Race Detection
10
13
11
-
Clock Vector Based detection can get very complex very quickly, thus this implementation doesn't quantities memory accesses but instead check after every access, thus the clock vector doesn't need to contain accurate timestamps(instead a memory access counter is used). This isn't very performant and the slowest, but also most simple method.
14
+
Clock Vector Based detection can get very complex, very quickly, thus this implementation doesn't quantities memory accesses but instead check after every access, thus the clock vector doesn't need to contain accurate timestamps(instead a memory access counter is used). This isn't very performant and the slowest, but also most simple method.
12
15
13
16
The mathematical operators and logic is described in [this](https://dl.acm.org/doi/pdf/10.1145/3018610.3018611)(section 3.12) paper quite well.
14
17
15
18
## Rough implementation summary
16
19
17
-
Most of the race detectors code comes down to collecting and preperation of data. The detector has per thread data and a global allocations array(which stores context information about allocated memory that has to be checked). The per thread data contains sets that store all reads/ writes relating to allocated memory as well as all lock accesses and states. Checks are performed on every memory access to allocated memory.
20
+
Most of the race detector's code comes down to collecting and preparation of data. The detector has per thread data and a global allocations/locks array(which stores context information about allocated memory that has to be checked, and lock states). The per thread data contains sets that store all reads/ writes relating to allocated memory, as well as all lock accesses and states. Checks are performed on every memory access to allocated memory.
// this is an event like fn that is envoked on every memory access (called by DynamRIO)
310
299
voidmemtrace(void*drcontext, u64thread_id) {
311
-
// printf("trace: %ld \n",thread_id );
312
300
if (drcontext==NULL) return;
313
301
per_thread_t*data;
314
302
mem_ref_t*mem_ref, *buf_ptr;
315
303
data=drmgr_get_tls_field(drcontext, tls_idx);
316
304
buf_ptr=BUF_PTR(data->seg_base);
317
305
318
-
i64t_index=find_thread_by_tid(thread_id);
319
-
if (t_index<0) return;
306
+
// todo => fix: mutex information is loaded from wrong thread. it's loaded from the last_locked_mutex_addr from the thread_accessed(the thread to which or from which the information is written/read) instead in which thread it took place.
0 commit comments