On Mon, Sep 30, 2013 at 11:22 PM, Philippe Waroquiers <
philippe.waroqui...@skynet.be> wrote:
> 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) ?
>
> > >
> > > 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
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
------------------------------------------------------------------------------
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
