|
From: John R. <jr...@bi...> - 2012-09-14 14:53:29
|
> In some build system where I work, as @rpm5.org popt, I am running the
> test suite using MALLOC_CHECK_ =3 always. A configure time I can
> also choose to run the test suite with valgrind .
The documentation mentions only {0,1,2} as values for MALLOC_CHECK_:
$ info libc
This is Edition 0.13, last updated 2011-07-19, of `The GNU C Library
Reference Manual', for Version 2.14 of the GNU C Library.
MALLOC_CHECK_ environment variable:
un-set: no checking
0: no checking
1: checking; write complaints to stderr
2: checking; abort() upon error
Perhaps the value of MALLOC_CHECK_ is used as a bitmap, so that
3 implies both 1 and 2; but this is not documented.
The documentation mentions the error classes: overrun by one byte,
double free(), and no others. Valgrind (memcheck) handles both of
those and more: use of uninitialized values, and memory leaks.
Memcheck wraps client calls to malloc(), and puts a "red zone" on each
end of each block in order to detect access overruns. Memcheck already
detects double free() (up to the limit of the buffer which remembers
pending free()). Thus memcheck subsumes all the documented coverage
of MALLOC_CHECK_.
If MALLOC_CHECK_ is set non-zero when running memcheck, then the
overruns that might be detected by MALLOC_CHECK_ would be overruns
on the wrapped blocks which include the red zones. Thus MALLOC_CHECK_
would be checking memcheck, and not the client. This is not useful,
and actually is wasteful. The only possible [documented] advantage
of using MALLOC_CHECK_ and memcheck together, would be if MALLOC_CHECK_
detected duplicate free() in more cases than memcheck because memcheck's
buffer is too small. See the memcheck parameters:
--freelist-vol=<number> volume of freed blocks queue [20000000]
--freelist-big-blocks=<number> releases first blocks with size >= [1000000]
Therefore in nearly all practical cases, do not use MALLOC_CHECK_
and valgrind(memcheck) at the same time. When running valgrind(memcheck),
then unset MALLOC_CHECK_ (or set MALLOC_CHECK_=0).
As long as you are conscientious enough to use MALLOC_CHECK_, then you
should consider also using MALLOC_PERTURB_ [which does not appear in
"info libc"]: Using MALLOC_PERTURB_ buys about 10% to 15% of the benefits
of memcheck checking for uninit bytes, but at very low runtime cost:
the cost of memset() before return from malloc(). In nearly all practical
cases this cost is small enough to ignore (at most a couple percent.)
# http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
echo 1>&2 MALLOC_PERTURB_=$MALLOC_PERTURB_ " # $HOME/.bash_profile"
--
|