Valgrind Frequently Asked Questions
3. Valgrind aborts unexpectedly
3.1.
Programs run OK on Valgrind, but at exit produce a bunch of errors involving
__libc_freeres
and then
die with a segmentation fault.
When the program exits, Valgrind runs the procedure
__libc_freeres
in glibc.
This is a hook for
memory debuggers, so they can ask glibc to free up any memory it has used. Doing that is needed to ensure
that Valgrind doesn’t incorrectly report space leaks in glibc.
The problem is that running
__libc_freeres
in older glibc versions causes this crash.
Workaround for 1.1.X and later versions of Valgrind: use the
--run-libc-freeres=no
option.
You
may then get space leak reports for glibc allocations (please don’t report these to the glibc people, since they
are not real leaks), but at least the program runs.
3.2.
My (buggy) program dies like this:
valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion ’bszB_lo == bszB_hi’ failed.
or like this:
valgrind: m_mallocfree.c:442 (mk_inuse_bszB): Assertion ’bszB != 0’ failed.
or otherwise aborts or crashes in m_mallocfree.c.
If Memcheck (the memory checker) shows any invalid reads, invalid writes or invalid frees in your program,
the above may happen. Reason is that your program may trash Valgrind’s low-level memory manager, which
then dies with the above assertion, or something similar. The cure is to fix your program so that it doesn’t do
any illegal memory accesses. The above failure will hopefully go away after that.
3.3.
My program dies, printing a message like this along the way:
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5
One possibility is that your program has a bug and erroneously jumps to a non-code address, in which case
you’ll get a SIGILL signal. Memcheck may issue a warning just before this happens, but it might not if the
jump happens to land in addressable memory.
Another possibility is that Valgrind does not handle the instruction.
If you are using an older Valgrind, a
newer version might handle the instruction.
However, all instruction sets have some obscure, rarely used
instructions. Also, on amd64 there are an almost limitless number of combinations of redundant instruction
prefixes, many of them undocumented but accepted by CPUs.
So Valgrind will still have decoding failures
from time to time. If this happens, please file a bug report.
3.4.
I tried running a Java program (or another program that uses a just-in-time compiler) under Valgrind but
something went wrong. Does Valgrind handle such programs?
3
