2012/9/14 John Reiser <[email protected]>: >> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/valgrind-users ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
