|
From: Elia P. <git...@gm...> - 2012-09-14 15:05:52
|
2012/9/14 John Reiser <jr...@bi...>:
>> 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"
>
Thanks all very much. Very useful and - beautiful - answers. And yes i
use MALLOC_PERTUB already.
Thanks again
> --
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|