DRD: a thread error detector
--ptrace-addr=<address> [default:
none]
Trace all load and store activity for the specified address and keep doing that even after the memory at that address has
been freed and reallocated.
--trace-alloc=<yes|no> [default:
no]
Trace all memory allocations and deallocations. May produce a huge amount of output.
--trace-barrier=<yes|no> [default:
no]
Trace all barrier activity.
--trace-cond=<yes|no> [default:
no]
Trace all condition variable activity.
--trace-fork-join=<yes|no> [default:
no]
Trace all thread creation and all thread termination events.
--trace-hb=<yes|no> [default:
no]
Trace
execution
of
the
ANNOTATE_HAPPENS_BEFORE()
,
ANNOTATE_HAPPENS_AFTER()
and
ANNOTATE_HAPPENS_DONE()
client requests.
--trace-mutex=<yes|no> [default:
no]
Trace all mutex activity.
--trace-rwlock=<yes|no> [default:
no]
Trace all reader-writer lock activity.
--trace-semaphore=<yes|no> [default:
no]
Trace all semaphore activity.
8.2.2. Detected Errors: Data Races
DRD prints a message every time it detects a data race. Please keep the following in mind when interpreting DRD’s
output:
• Every thread is assigned a
thread ID
by the DRD tool. A thread ID is a number. Thread ID’s start at one and are
never recycled.
• The term
segment
refers to a consecutive sequence of load, store and synchronization operations, all issued by the
same thread. A segment always starts and ends at a synchronization operation. Data race analysis is performed
between segments instead of between individual load and store operations because of performance reasons.
• There are always at least two memory accesses involved in a data race. Memory accesses involved in a data race are
called
conflicting memory accesses
. DRD prints a report for each memory access that conflicts with a past memory
access.
125
