|
From: Olly B. <ol...@su...> - 2003-10-22 18:29:49
|
I noticed that valgrind now automatically detects a few situations which
would previous often caused an FAQ to be asked - it now detects statically
linked and setuid programs for example.
It struck me that this is a useful trend, so I had a look at the FAQ to
see if there were other tests we could add to preempt the questions.
I'm willing to work on this if it's considered worthwhile, but the best
approach isn't always obvious.
Looking at the CVS HEAD FAQ.txt:
| A mini-FAQ for valgrind, version 1.9.6
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Last revised 5 May 2003
| ~~~~~~~~~~~~~~~~~~~~~~~
As a side note, this is wrong and a little confusing as it suggests the
FAQ list isn't actively maintained.
| 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.
Which glibc versions are affected isn't covered, and I can't find the info
in the glibc NEWS or changelog, but if it were known, the best fix would
seem to be to automatically turn on --run-libc-freeres=no if
__libc_freeres() would cause this crash, and print a warning message
that explains this and points out that any space leaks in glibc may be
bogus.
[FAQ2]
| 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.
__NR_fstat64 is no longer used in the valgrind source (and is now
defined by them) so I think FAQ 2 no longer applies. Perhaps the
fix should be shortened to "Upgrade to the latest version of valgrind"?
| 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.
Would it be more helpful for --trace-children to be a 3-state with
values "yes", "no", and "warn" (the new default)?
The new value "warn" wouldn't trace children, but if a child process was
started, it would warn that it wouldn't be traced.
| Q8. My program dies (exactly) like this:
|
| REPE then 0xF
| valgrind: the `impossible' happened:
| Unhandled REPE case
The valgrind source no longer contains this panic message. Should the
answer suggest upgrading, as valgrind handles many SSE and SSE2
instructions now?
Cheers,
Olly
|