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

[Philippe W. <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) ?

> >
> > 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