mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-05 19:13:46 +00:00
fb2d543ee8
the places that normal users will see:
- command line: --tool=foo (although --skin=foo still works)
- docs: removed all traces (included renaming coregrind_skins.html to
coregrind_tools.html)
- in the usage messages
- in error messages
Also did in in some places that I judged were unlikely to cause clashes with
existing workspaces:
- in the header comments of many files (eg. "This file is part of Memcheck, a
Valgrind tool for...")
- in the regtests script
- in the .supp files
- in AUTHORS
- in README_MISSING_SYSCALL_OR_IOCTL
Also update the AUTHORS file to mention Jeremy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2027
61 lines
2.1 KiB
HTML
61 lines
2.1 KiB
HTML
|
|
<html>
|
|
<head>
|
|
<title>Helgrind: a data-race detector</title>
|
|
</head>
|
|
|
|
<a name="hg-top"></a>
|
|
<h2>6 Helgrind: a data-race detector</h2>
|
|
|
|
To use this tool, you must specify <code>--tool=helgrind</code> on the
|
|
Valgrind command line.
|
|
<p>
|
|
|
|
Helgrind is a Valgrind tool for detecting data races in C and C++ programs
|
|
that use the Pthreads library.
|
|
<p>
|
|
It uses the Eraser algorithm described in
|
|
<blockquote>
|
|
Eraser: A Dynamic Data Race Detector for Multithreaded Programs<br>
|
|
Stefan Savage, Michael Burrows, Greg Nelson, Patrick Sobalvarro and
|
|
Thomas Anderson<br>
|
|
ACM Transactions on Computer Systems, 15(4):391-411<br>
|
|
November 1997.
|
|
</blockquote>
|
|
|
|
We also incorporate significant improvements from this paper:
|
|
|
|
<blockquote>
|
|
Runtime Checking of Multithreaded Applications with Visual Threads
|
|
Jerry J. Harrow, Jr.<br>
|
|
Proceedings of the 7th International SPIN Workshop on Model Checking of
|
|
Software<br>
|
|
Stanford, California, USA<br>
|
|
August 2000<br>
|
|
LNCS 1885, pp331--342<br>
|
|
K. Havelund, J. Penix, and W. Visser, editors.<br>
|
|
</blockquote>
|
|
|
|
<p>
|
|
Basically what Helgrind does is to look for memory locations which are
|
|
accessed by more than one thread. For each such location, Helgrind
|
|
records which of the program's (pthread_mutex_)locks were held by the
|
|
accessing thread at the time of the access. The hope is to discover
|
|
that there is indeed at least one lock which is used by all threads to
|
|
protect that location. If no such lock can be found, then there is
|
|
(apparently) no consistent locking strategy being applied for that
|
|
location, and so a possible data race might result.
|
|
<p>
|
|
Helgrind also allows for "thread segment lifetimes". If the execution of two
|
|
threads cannot overlap -- for example, if your main thread waits on another
|
|
thread with a <code>pthread_join()</code> operation -- they can both access the
|
|
same variable without holding a lock.
|
|
<p>
|
|
There's a lot of other sophistication in Helgrind, aimed at
|
|
reducing the number of false reports, and at producing useful error
|
|
reports. We hope to have more documentation one day...
|
|
|
|
</body>
|
|
</html>
|
|
|