Valgrind Frequently Asked Questions
Valgrind can handle dynamically generated code, so long as none of the generated code is later overwritten
by other generated code.
If this happens, though, things will go wrong as Valgrind will continue running
its translations of the old code (this is true on x86 and amd64, on PowerPC there are explicit cache flush
instructions which Valgrind detects and honours). You should try running with
--smc-check=all
in this
case. Valgrind will run much more slowly, but should detect the use of the out-of-date code.
Alternatively,
if you have the source code to the JIT compiler you can insert calls to the
VALGRIND_DISCARD_TRANSLATIONS
client request to mark out-of-date code, saving you from
using
--smc-check=all
.
Apart from this, in theory Valgrind can run any Java program just fine, even those that use JNI and are partially
implemented in other languages like C and C++.
In practice, Java implementations tend to do nasty things
that most programs do not, and Valgrind sometimes falls over these corner cases.
If your Java programs do not run under Valgrind, even with
--smc-check=all
, please file a bug report and
hopefully we’ll be able to fix the problem.
4. Valgrind behaves unexpectedly
4.1.
My program uses the C++ STL and string classes. Valgrind reports ’still reachable’ memory leaks involving
these classes at the exit of the program, but there should be none.
First of all: relax, it’s probably not a bug, but a feature. Many implementations of the C++ standard libraries
use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately
freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed
at the exit of the program cause Valgrind to report this memory as still reachable. The behaviour not to free
pools at the exit could be called a bug of the library though.
Using GCC, you can force the STL to use malloc and to free memory as soon as possible by globally disabling
memory caching. Beware! Doing so will probably slow down your program, sometimes drastically.
• With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using the STL with
-D__USE_MALLOC
. Beware!
This was removed from GCC starting with version 3.3.
• With GCC 3.2.2 and later, you should export the environment variable
GLIBCPP_FORCE_NEW
before
running your program.
• With GCC 3.4 and later, that variable has changed name to
GLIBCXX_FORCE_NEW
.
There are other ways to disable memory pooling: using the
malloc_alloc
template with your objects (not
portable, but should work for GCC) or even writing your own memory allocators. But all this goes beyond the
scope of this FAQ. Start by reading http://gcc.gnu.org/onlinedocs/+/faq/index.html#4_4_leak if you
absolutely want to do that. But beware: allocators belong to the more messy parts of the STL and people went
to great lengths to make the STL portable across platforms. Chances are good that your solution will work on
your platform, but not on others.
4.2.
The stack traces given by Memcheck (or another tool) aren’t helpful. How can I improve them?
4
Содержание 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 ...