|
From: Elia P. <git...@gm...> - 2012-09-14 13:21:46
|
Hi to all
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 .
In this way i can execute sometime valgrind and the check due to MALLOC_CHECK_
simultaneously. I have never had any problems in doing this.
But the maintainer git asked me about this recently because he have
some dubt about
and so I would give a qualified answer. Anyway i am also interessed
for my projects.
Quoting it
"If you are using valgrind to run tests, is it sane to also enable
MALLOC_CHECK? If you were testing "cat", would it make sense to do:
$ MALLOC_CHECK_=3 valgrind cat README
Because we are not interested in testing how valgrind (not cat)
uses malloc, we may be better off running
$ valgrind cat README
without MALLOC_CHECK_; it will reduce the risk of MALLOC_CHECK_
potentially disturbing what we really want to check (i.e. cat) by
triggering for something whose problems we are not trying to see
(i.e. valgrind), no?"
http://www.spinics.net/lists/git/msg188833.html
I dod not find anything about this subject searching on the web.
Thank you very much in advance
|
|
From: Tom H. <to...@co...> - 2012-09-14 14:09:19
|
On 14/09/12 14:21, Elia Pinto wrote: > "If you are using valgrind to run tests, is it sane to also enable > MALLOC_CHECK? If you were testing "cat", would it make sense to do: > > $ MALLOC_CHECK_=3 valgrind cat README I think you'll find that the MALLOC_CHECK_ does precisely nothing when you do this because neither valgrind not cat will be using the glibc malloc in any way. Memory allocation for valgrind is done using valgrind's own allocator and when valgrinding a program using the default memcheck tool the normal malloc will be overridden to use valgrind's version so that we can track what blocks are allocated. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
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"
--
|
|
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
|
|
From: Elia P. <git...@gm...> - 2012-09-14 15:18:02
|
2012/9/14 John Reiser <jr...@bi...>:
> 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.
Sorry forgot. Yes it is like a bitmap
http://www.novell.com/support/kb/doc.php?id=3113982
Best Regards
|