Valgrind Software, Быстрый старт

Страница: 132 / 319

Helgrind: a thread error detector
--check-stack-refs=no|yes [default: yes]
By default Helgrind checks all data memory accesses made by your program. This flag enables you to skip checking
for accesses to thread stacks (local variables). This can improve performance, but comes at the cost of missing races
on stack-allocated data.
7.7. Helgrind Client Requests
The following client requests are defined in helgrind.h . See that file for exact details of their arguments.
•
VALGRIND_HG_CLEAN_MEMORY
This makes Helgrind forget everything it knows about a specified memory range. This is particularly useful for
memory allocators that wish to recycle memory.
•
ANNOTATE_HAPPENS_BEFORE
•
ANNOTATE_HAPPENS_AFTER
•
ANNOTATE_NEW_MEMORY
• ANNOTATE_RWLOCK_CREATE
• ANNOTATE_RWLOCK_DESTROY
•
ANNOTATE_RWLOCK_ACQUIRED
•
ANNOTATE_RWLOCK_RELEASED
These are used to describe to Helgrind, the behaviour of custom (non-POSIX) synchronisation primitives, which it
otherwise has no way to understand. See comments in
helgrind.h
for further documentation.
7.8. A To-Do List for Helgrind
The following is a list of loose ends which should be tidied up some time.
• For lock order errors, print the complete lock cycle, rather than only doing for size-2 cycles as at present.
• The conflicting access mechanism sometimes mysteriously fails to show the conflicting access’ stack, even when
provided with unbounded storage for conflicting access info. This should be investigated.
• Document races caused by GCC’s thread-unsafe code generation for speculative stores. In the interim see
http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html and http://lkml.org/lkml/2007/10/24/673 .
• Don’t update the lock-order graph, and don’t check for errors, when a "try"-style lock operation happens (e.g.
pthread_mutex_trylock
). Such calls do not add any real restrictions to the locking order, since they can
always fail to acquire the lock, resulting in the caller going off and doing Plan B (presumably it will have a Plan B).
Doing such checks could generate false lock-order errors and confuse users.
• Performance can be very poor. Slowdowns on the order of 100:1 are not unusual. There is limited scope for
performance improvements.
120