DRD: a thread error detector
• To know where the scope ends of POSIX objects that have not been destroyed explicitly. It is e.g. not required
by the POSIX threads standard to call
pthread_mutex_destroy
before freeing the memory in which a mutex
object resides.
• To know where the scope of variables ends. If e.g. heap memory has been used by one thread, that thread frees that
memory, and another thread allocates and starts using that memory, no data races must be reported for that memory.
It is essential for correct operation of DRD that the tool knows about memory allocation and deallocation events. When
analyzing a client program with DRD that uses a custom memory allocator, either instrument the custom memory
allocator with the
VALGRIND_MALLOCLIKE_BLOCK
and
VALGRIND_FREELIKE_BLOCK
macros or disable the
custom memory allocator.
As an example, the GNU + library can be configured to use standard memory allocation functions instead
of memory pools by setting the environment variable
GLIBCXX_FORCE_NEW
. For more information, see also the
+ manual.
8.2.10. DRD Versus Memcheck
It is essential for correct operation of DRD that there are no memory errors such as dangling pointers in the client
program. Which means that it is a good idea to make sure that your program is Memcheck-clean before you analyze
it with DRD. It is possible however that some of the Memcheck reports are caused by data races. In this case it makes
sense to run DRD before Memcheck.
So which tool should be run first? In case both DRD and Memcheck complain about a program, a possible approach
is to run both tools alternatingly and to fix as many errors as possible after each run of each tool until none of the two
tools prints any more error messages.
8.2.11. Resource Requirements
The requirements of DRD with regard to heap and stack memory and the effect on the execution time of client programs
are as follows:
• When running a program under DRD with default DRD options, between 1.1 and 3.6 times more memory will be
needed compared to a native run of the client program. More memory will be needed if loading debug information
has been enabled (
--read-var-info=yes
).
• DRD allocates some of its temporary data structures on the stack of the client program threads. This amount of data
is limited to 1 - 2 KB. Make sure that thread stacks are sufficiently large.
• Most applications will run between 20 and 50 times slower under DRD than a native single-threaded run. The
slowdown will be most noticeable for applications which perform frequent mutex lock / unlock operations.
8.2.12. Hints and Tips for Effective Use of DRD
The following information may be helpful when using DRD:
• Make sure that debug information is present in the executable being analyzed, such that DRD can print function
name and line number information in stack traces. Most compilers can be told to include debug information via
compiler option
-g
.
133
Содержание BBV
Страница 176: ...Valgrind FAQ Release 3 8 0 10 August 2012 Copyright 2000 2012 Valgrind Developers Email valgrind valgrind org ...
Страница 177: ...Valgrind FAQ Table of Contents Valgrind Frequently Asked Questions 1 ii ...
Страница 302: ...README mips based on newer GCC versions if possible 95 ...
Страница 303: ...GNU Licenses ...
Страница 304: ...GNU Licenses Table of Contents 1 The GNU General Public License 1 2 The GNU Free Documentation License 8 ii ...