Hello Philippe,
2013/10/1 Philippe Waroquiers <philippe.waroqui...@skynet.be>
> On Mon, 2013-09-30 at 14:49 +0400, Konstantin Tokarev wrote:
> > 30.09.2013, 03:15, "Lu Mitnick" <king19880...@gmail.com>:
> > > Hello all,
> > >
> > > Memcheck could be used to detect different type of bugs:
> > > 1. illegal read/write
> > > 2. use of uninitialised values
> > > 3. illegal frees
> > > 4. when a heap block is freed with an inappropriate deallocation
> function
> > > ...
> > >
> > > I am wondering whether it is possible to use valgrind to check
> specified bug types? In other words, I would like to use memcheck to only
> check addressable bug, illegal frees bug and allocation/deallocation
> routine mismatched bug in the first run. Then check the use of
> uninitialised values bug in the second run.
> What is the reason to do two runs rather than one single run (reporting
> all found problems) ?
I would like to know the performance number for detection of each type of
bug, ie. the execution time when the Valgrind only
detect illegal read/write, or the execution time when the Valgrind only
detect use of uninitialised values ... etc. Is it possible to
check specified bugs?
> > >
> > > Thanks a lot.
> >
> > You can use AddressSanitizer (clang 3.0+ or gcc 4.8+) for the first run.
> As a bonus point it does not cause so heavy
> > slowdown as valgrind and provides more verbose info for bugs like use
> after free (trace when it was allocated,
> > when it was deleted, and when it was used, while memcheck shows only the
> last one).
> Valgrind 3.8.1 (and before) gives the stack traces of the
> 'use after free' and and where it was freed.
>
> In Valgrind 3.9.0 SVN, the option
> --keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none
> stack trace(s) to keep for malloc'd/free'd areas
> [alloc-then-free]
> allows to specify what to keep, giving e.g.
>
> ==2495== Invalid write of size 1
> ==2495== at 0x804844A: really (malloc1.c:20)
> ==2495== by 0x80483FE: main (malloc1.c:9)
> ==2495== Address 0x4028029 is 1 bytes inside a block of size 10 free'd
> ==2495== at 0x4006CC2: free (vg_replace_malloc.c:468)
> ==2495== by 0x8048443: really (malloc1.c:19)
> ==2495== by 0x80483FE: main (malloc1.c:9)
> ==2495== block was alloc'd at
> ==2495== at 0x40072D5: malloc (vg_replace_malloc.c:291)
> ==2495== by 0x8048419: really (malloc1.c:16)
> ==2495== by 0x80483FE: main (malloc1.c:9)
>
> Otherwise, the option --undef-value-errors=no|yes allows to disable/enable
> checking
> for undef values. --undef-value-errors=no more or less doubles the speed
> (measured on bz2 on x86-64).
>
> To my knowledge, Address sanitizer does not detect mismatch between alloc
> and free fn
> (which memcheck does) but it finds overruns in stack and global vars
>
> Philippe
>
>
>
Thanks a lot
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
