Menu
▾
▴
valgrind-users
|
From: Lu M. <kin...@gm...> - 2013-09-29 23:13:37
|
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. Thanks a lot. |
|
From: Konstantin T. <an...@ya...> - 2013-09-30 10:49:44
|
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. > > 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). -- Regards, Konstantin |
|
From: Philippe W. <phi...@sk...> - 2013-09-30 19:21:56
|
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
|
|
From: Konstantin S. <kon...@gm...> - 2013-10-01 11:33:33
|
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
>
>
>
|
|
From: Philippe W. <phi...@sk...> - 2013-10-01 18:57:46
|
On Tue, 2013-10-01 at 15:33 +0400, Konstantin Serebryany wrote: > > On Mon, Sep 30, 2013 at 11:22 PM, Philippe Waroquiers > <phi...@sk...> wrote: > > > To my knowledge, Address sanitizer does not detect mismatch > > between alloc and free fn > > > It does: Oops, yes. My theoretical knowledge stopped at http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer I did not look at the flags section. Philippe |
|
From: Lu M. <kin...@gm...> - 2013-10-07 04:18:58
|
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 |
|
From: Brad H. <br...@fr...> - 2013-10-07 09:35:23
|
On Mon, 7 Oct 2013 12:18:51 PM Lu Mitnick wrote: > 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? Is this some academic / theoretical exercise? The problem is that the detection of a single type of bug isn't well separated. So the cost of detecting bug type X and the cost of detecting bug type Y is going to have a lot of common factors (all the tracking work). If its academic, I'd suggest modifying the code to extract the numbers you want to show. It probably won't be very meaningful, but it is what it is. If its not academic, please explain why you are trying to do this (not just what) - some context, so we can provide something that can help you solve your real problem. Brad |
Thanks for helping keep SourceForge clean.
X