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

[Konstantin S. <kon...@gm...>]

On Mon, Sep 30, 2013 at 11:22 PM, Philippe Waroquiers <
phi...@sk...> wrote:

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

It does:
% cat  malloc_delete_mismatch.cc
#include <stdlib.h>
static volatile char *x;
int main() {
  x = (char*)malloc(10);
  x[0] = 0;
  delete x;
}
% clang++ -g malloc_delete_mismatch.cc -fsanitize=address && ./a.out
=================================================================
==416==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator
delete) on 0x60200000eff0
    #0 0x4450b6 in operator delete(void*)
/home/kcc/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:83
    #1 0x4588c7 in main /tmp/malloc_delete_mismatch.cc:6
    #2 0x7f586d9c676c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
0x60200000eff0 is located 0 bytes inside of 10-byte region
[0x60200000eff0,0x60200000effa)
allocated by thread T0 here:
    #0 0x4446c6 in malloc
/home/kcc/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
    #1 0x458849 in main /tmp/malloc_delete_mismatch.cc:4
    #2 0x7f586d9c676c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch
/home/kcc/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:83 operator
delete(void*)
==416==HINT: if you don't care about these warnings you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==416==ABORTING
% g++ malloc_delete_mismatch.cc -fsanitize=address -static-libasan &&
./a.out
=================================================================
==596==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator
delete) on 0x60200000eff0
    #0 0x4397ec in operator delete(void*) (/tmp/a.out+0x4397ec)
    #1 0x44bf15 in main (/tmp/a.out+0x44bf15)
    #2 0x7f993e15476c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
0x60200000eff0 is located 0 bytes inside of 10-byte region
[0x60200000eff0,0x60200000effa)
allocated by thread T0 here:
    #0 0x438ce4 in malloc (/tmp/a.out+0x438ce4)
    #1 0x44bec1 in main (/tmp/a.out+0x44bec1)
    #2 0x7f993e15476c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch ??:0 operator
delete(void*)
==596==HINT: if you don't care about these warnings you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==596==ABORTING
%



> (which memcheck does) but it finds overruns in stack and global vars
>

true. :)

Of course, AddressSanitizer remains blind to uninits.

--kcc


>
> Philippe
>
>
>
>
> ------------------------------------------------------------------------------
> 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=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>