Menu
▾
▴
[Valgrind-users] Majorly expanded FAQ
|
From: Julian S. <js...@ac...> - 2003-04-22 23:30:40
|
Greetings. We've majorly expanded the FAQ to include workarounds for more
or less all failure conditions for which we know a workaround. This includes
a large fraction of the failures people seem to encounter in practice, so
if you've been having problems with V it might be worth taking a look.
The FAQ is below, and we'll included it in all future distributions.
I'll also put it up on the web site.
J
A mini-FAQ for valgrind, version 1.9.6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last revised 22 Apr 2003
~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------------------------------------------
Q1. Programs run OK on valgrind, but at exit produce a bunch
of errors a bit like this
==20755== Invalid read of size 4
==20755== at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
==20755== by 0x4028179D: free_mem (findlocale.c:257)
==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
==20755== by 0x40048DCC: vgPlain___libc_freeres_wrapper
(vg_clientfuncs.c:585)
==20755== Address 0x40CC304C is 8 bytes inside a block of size 380
free'd
==20755== at 0x400484C9: free (vg_clientfuncs.c:180)
==20755== by 0x40281CBA: _nl_unload_locale (loadlocale.c:246)
==20755== by 0x40281218: free_mem (setlocale.c:461)
==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
and then die with a segmentation fault.
A1. 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.
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 flag. 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.
-----------------------------------------------------------------
Q2. My program dies complaining that syscall 197 is unimplemented.
A2. 197, which is fstat64, is supported by valgrind. The problem is
that the /usr/include/asm/unistd.h on the machine on which your
valgrind was built, doesn't match your kernel -- or, to be more
specific, glibc is asking your kernel to do a syscall which is
not listed in /usr/include/asm/unistd.h.
The fix is simple. Somewhere near the top of
coregrind/vg_syscalls.c, add the following line:
#define __NR_fstat64 197
Rebuild and try again. The above line should appear before any
uses of the __NR_fstat64 symbol in that file. If you look at the
place where __NR_fstat64 is used in vg_syscalls.c, it will be
obvious why this fix works.
-----------------------------------------------------------------
Q3. My (buggy) program dies like this:
valgrind: vg_malloc2.c:442 (bszW_to_pszW):
Assertion `pszW >= 0' failed.
And/or my (buggy) program runs OK on valgrind, but dies like
this on cachegrind.
A3. If valgrind shows any invalid reads, invalid writes and 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 like this. 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.
-----------------------------------------------------------------
Q4. I'm running Red Hat Advanced Server. Valgrind always segfaults at
startup.
A4. Known issue with RHAS 2.1, due to funny stack permissions at
startup. However, valgrind-1.9.4 and later automatically handle
this correctly, and should not segfault.
-----------------------------------------------------------------
Q5. I try running "valgrind my_program", but my_program runs normally,
and Valgrind doesn't emit any output at all.
A5. Is my_program statically linked? Valgrind doesn't work with
statically linked binaries. It must rely on at least one shared
object. To detrmine if a my_program is statically linked, run:
ldd my_program
It will show what shared objects my_program relies on, or say:
not a dynamic executable
it my_program is statically linked.
-----------------------------------------------------------------
Q6. I try running "valgrind my_program" and get Valgrind's startup message,
but I don't get any errors and I know my program has errors.
A6. By default, Valgrind only traces the top-level process. So if your
program spawns children, they won't be traced by Valgrind by default.
Also, if your program is started by a shell script, Perl script, or
something similar, Valgrind will trace the shell, or the Perl
interpreter, or equivalent.
To trace child processes, use the --trace-children=yes option.
If you are tracing large trees of processes, it can be less
disruptive to have the output sent over the network. Give
valgrind the flag --logsocket=127.0.0.1:12345 (if you want
logging output sent to port 12345 on localhost). You can
use the valgrind-listener program to listen on that port:
valgrind-listener 12345
Obviously you have to start the listener process first.
See the documentation for more details.
-----------------------------------------------------------------
Q7. My threaded server process runs unbelievably slowly on
valgrind. So slowly, in fact, that at first I thought it
had completely locked up.
A7. We are not completely sure about this, but one possibility
is that laptops with power management fool valgrind's
timekeeping mechanism, which is (somewhat in error) based
on the x86 RDTSC instruction. A "fix" which is claimed to
work is to run some other cpu-intensive process at the same
time, so that the laptop's power-management clock-slowing
does not kick in. We would be interested in hearing more
feedback on this.
-----------------------------------------------------------------
Q8. My program dies (exactly) like this:
REPE then 0xF
valgrind: the `impossible' happened:
Unhandled REPE case
A8. Yeah ... that I believe is a P4 specific instruction. Are you
building your app with -march=pentium4 or something like that?
Others have reported that removing the flag works around this.
In fact this is pretty easy to fix and I do have it on my
to-do-for-1.9.6 list.
I'd be interested to hear if you can get rid of it by changing
your application build flags.
-----------------------------------------------------------------
Q9. My program dies complaining that __libc_current_sigrtmin
is unimplemented.
A9. Try the following. It is an experiment, but it might work.
We would very much appreciate you telling us if it does/
does not work for you.
In vg_libpthread.c, add the 3 functions below.
In vg_libpthread_unimp.c, remove the stubs for the same 3
functions.
Let me know if it helps. Quite a lot of other valgrind users
complain about this, but I have never been able to reproduce it,
so fixing it isn't easy. So it's useful if you can try.
int __libc_current_sigrtmin (void)
{
return -1;
}
int __libc_current_sigrtmax (void)
{
return -1;
}
int __libc_allocate_rtsig (int high)
{
return -1;
}
-----------------------------------------------------------------
Q10. I upgraded to Red Hat 9 and threaded programs now act
strange / deadlock when they didn't before.
A10. Thread support on glibc 2.3.2+ with NPTL is not as
good as on older LinuxThreads-based systems. We have
this under consideration. Avoid Red Hat >= 8.1 for
the time being, if you can.
-----------------------------------------------------------------
Q11. I really need to use the NVidia libGL.so in my app.
Help!
A11. NVidia also noticed this it seems, and the "latest" drivers
(version 4349, apparently) come with this text
DISABLING CPU SPECIFIC FEATURES
Setting the environment variable __GL_FORCE_GENERIC_CPU to a
non-zero value will inhibit the use of CPU specific features
such as MMX, SSE, or 3DNOW!. Use of this option may result in
performance loss. This option may be useful in conjunction with
software such as the Valgrind memory debugger.
Set __GL_FORCE_GENERIC_CPU=1 and Valgrind should work. This has
been confirmed by various people. Thanks NVidia!
-----------------------------------------------------------------
Q12. My program dies like this (often at exit):
VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
(loads of text)
A12. We're not entirely sure about this, and would appreciate
someone sending a simple test case for us to look at.
One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Avoid this if you can.
In any case, you may be able to work around it like this:
Comment out the
call to VG_(core_panic) at coregrind/vg_main.c:1647 and see
if that helps. The text of coregrind/vg_main.c:1647 is as follows:
VG_(core_panic)("VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH) failed\n");
and so it's this call you want to comment out.
-----------------------------------------------------------------
Q13. My program dies like this:
error: /lib/librt.so.1: symbol __pthread_clock_settime, version
GLIBC_PRIVATE not defined in file libpthread.so.0 with link time
reference
A13. This is a total swamp. Nevertheless there is a way out.
It's a problem which is not easy to fix. Really the problem is
that /lib/librt.so.1 refers to some symbols
__pthread_clock_settime and __pthread_clock_gettime in
/lib/libpthread.so which are not intended to be exported, ie
they are private.
Best solution is to ensure your program does not use
/lib/librt.so.1.
However .. since you're probably not using it directly, or even
knowingly, that's hard to do. You might instead be able to fix
it by playing around with coregrind/vg_libpthread.vs. Things to
try:
Remove this
GLIBC_PRIVATE {
__pthread_clock_gettime;
__pthread_clock_settime;
};
or maybe remove this
GLIBC_2.2.3 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
or maybe add this
GLIBC_2.2.4 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
GLIBC_2.2.5 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
or some combination of the above. After each change you need to
delete coregrind/libpthread.so and do make && make install.
I just don't know if any of the above will work. If you can
find a solution which works, I would be interested to hear it.
To which someone replied:
I deleted this:
GLIBC_2.2.3 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
and it worked.
-----------------------------------------------------------------
(this is the end of the FAQ.)
|
