Re: [Valgrind-users] Is it possible to check specified bugs?

[Lu M. <kin...@gm...>]

Hello Philippe,


2013/10/1 Philippe Waroquiers <phi...@sk...>

> On Mon, 2013-09-30 at 14:49 +0400, Konstantin Tokarev wrote:
> > 30.09.2013, 03:15, "Lu Mitnick" <kin...@gm...>:
> > > 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