Menu
▾
▴
valgrind-users
|
From: Nick S. <sa...@ya...> - 2013-12-20 18:17:04
|
Hi all, Valgrind's typical output ==19182== Invalid write of size 4 ==19182== at 0x804838F: f (example.c:6) ==19182== by 0x80483AB: main (example.c:11) ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) ==19182== by 0x8048385: f (example.c:5) ==19182== by 0x80483AB: main (example.c:11) is not very diff-friendly. Is there a way to suppress process id and address printing? Perhaps something like ==?????== Invalid write of size 4 ==?????== at 0x???????: f (example.c:6) ==?????== by 0x???????: main (example.c:11) ==?????== Address 0x??????? is 0 bytes after a block of size 40 alloc'd ==?????== at 0x???????: malloc (vg_replace_malloc.c:130) ==?????== by 0x???????: f (example.c:5) ==?????== by 0x???????: main (example.c:11) or ==== Invalid write of size 4 ==== at : f (example.c:6) ==== by : main (example.c:11) ==== Address is 0 bytes after a block of size 40 alloc'd ==== at : malloc (vg_replace_malloc.c:130) ==== by : f (example.c:5) ==== by : main (example.c:11) Or is there a better way? Thanks, Nick |
|
From: David D. <dav...@gm...> - 2013-12-20 19:05:06
|
I had a similar problem, and ended up filtering all the addresses and identifiers out, so I could to a diff. Since sometimes address are not as important as names, I wonder what kinds of indirection could be done to "hide" the addresses and stuff.. On Fri, Dec 20, 2013 at 10:16 AM, Nick Savoiu <sa...@ya...> wrote: > > > Hi all, > > Valgrind's typical output > > > ==19182== Invalid write of size 4 > > ==19182== at 0x804838F: f (example.c:6) > > ==19182== by 0x80483AB: main (example.c:11) > > ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd > > ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) > > ==19182== by 0x8048385: f (example.c:5) > > ==19182== by 0x80483AB: main (example.c:11) > > is not very diff-friendly. Is there a way to suppress process id and > address printing? Perhaps something like > > ==?????== Invalid write of size 4 > ==?????== at 0x???????: f (example.c:6) > ==?????== by 0x???????: main (example.c:11) > ==?????== Address 0x??????? is 0 bytes after a block of size 40 alloc'd > ==?????== at 0x???????: malloc (vg_replace_malloc.c:130) > ==?????== by 0x???????: f (example.c:5) > ==?????== by 0x???????: main (example.c:11) > > > or > ==== Invalid write of size 4 > ==== at : f (example.c:6) > ==== by : main (example.c:11) > ==== Address is 0 bytes after a block of size 40 alloc'd > ==== at : malloc (vg_replace_malloc.c:130) > ==== by : f (example.c:5) > ==== by : main (example.c:11) > > > Or is there a better way? > > Thanks, > Nick > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Alan M. <ala...@jp...> - 2013-12-20 19:14:48
|
I use grep when I invoke valgrind in my makefile (where the valgrind
output from my entire regression suite is concatenated into
/tmp/valgrind.report):
grep -v STACK /tmp/valgrind.report | grep -v allocs | \
grep -v 'memory error detector' | grep -iv copyright | \
grep -v 'counts of detected' | grep -v 'HEAP SUMMARY' | \
grep -v checked | sed 's/==[0-9]*== //' | \
sed 's/(suppressed: [0-9]* from [0-9]*)//' >valgrind.report
On 12/20/2013 11:04 AM, David Dyck wrote:
> I had a similar problem, and ended up filtering all the addresses and
> identifiers out, so I could to a diff.
>
> Since sometimes address are not as important as names, I wonder what
> kinds of indirection could be done to "hide" the addresses and stuff..
>
>
> On Fri, Dec 20, 2013 at 10:16 AM, Nick Savoiu <sa...@ya...
> <mailto:sa...@ya...>> wrote:
>
>
>
> Hi all,
>
> Valgrind's typical output
>
>
> ==19182== Invalid write of size 4
>
> ==19182== at 0x804838F: f (example.c:6)
>
> ==19182== by 0x80483AB: main (example.c:11)
>
> ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40
> alloc'd
>
> ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
>
> ==19182== by 0x8048385: f (example.c:5)
>
> ==19182== by 0x80483AB: main (example.c:11)
>
> is not very diff-friendly. Is there a way to suppress process id
> and address printing? Perhaps something like
>
> ==?????== Invalid write of size 4
> ==?????== at 0x???????: f (example.c:6)
> ==?????== by 0x???????: main (example.c:11)
> ==?????== Address 0x??????? is 0 bytes after a block of size 40
> alloc'd
> ==?????== at 0x???????: malloc (vg_replace_malloc.c:130)
> ==?????== by 0x???????: f (example.c:5)
> ==?????== by 0x???????: main (example.c:11)
>
>
> or
> ==== Invalid write of size 4
> ==== at : f (example.c:6)
> ==== by : main (example.c:11)
> ==== Address is 0 bytes after a block of size 40 alloc'd
> ==== at : malloc (vg_replace_malloc.c:130)
> ==== by : f (example.c:5)
> ==== by : main (example.c:11)
>
>
> Or is there a better way?
>
> Thanks,
> Nick
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business.
> Most IT
> organizations don't have a clear picture of how application
> performance
> affects their revenue. With AppDynamics, you get 100% visibility
> into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> <mailto:Val...@li...>
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Mark R. <ma...@cs...> - 2013-12-20 19:51:46
Attachments:
clean-output.pl
|
We use a perl script (attached and below) to filter output before diffing.
Mark
#!/usr/bin/env perl
my $machine_type;
chomp($machine_type = `uname -m`);
while (<>) {
s/: +[0-9]+ Aborted +/: Aborted: /;
s/\(core dumped\) *//;
s/==\d+==/==PID==/;
if ($machine_type eq "x86_64") {
# Valgrind AMD64/Linux locations
s/0x7f([0-9a-f]{7,10})/<STACK_ADDR>/ig; # stack
s/0x4[01]([0-9a-f]{7})/<STATIC_ADDR>/ig; # r/w data
s/0x4[cd]([0-9a-f]{5})/<HEAP_ADDR>/ig; # heap ArrayTest because
so much allocated?
s/0x5[1a]([0-9a-f]{5})/<HEAP_ADDR>/ig; # heap
s/0x4[01]([0-9a-f]{4})/<STATIC_ADDR>/ig; # r/o data
s/0x6[01]([0-9a-f]{4})/<STATIC_ADDR>/ig; # r/w data
} else {
# we just assume ...
# Valgrind X86/Linux locations
s/0xb[ef]([0-9a-f]{6})/<STACK_ADDR>/ig; # stack
s/0x6[123]([0-9a-f]{6})/<STATIC_ADDR>/ig;# r/w data
s/0x4[0-8]([0-9a-f]{5})/<HEAP_ADDR>/ig; # heap
s/0x8[01]([0-9a-f]{5})/<STATIC_ADDR>/ig; # r/o and r/w data
}
# old/unused address substitutions
# s/0xf[ef]([0-9a-f]{6})/<STACK_ADDR>/ig; # Valgrind 32-on-64/Linux
location
# s/0x6[0-3]([0-9a-f]{5})/<HEAP_ADDR>/ig; # Valgrind 32-on-64/Linux
location
# s/0x5[01]([0-9a-f]{4})/<STATIC_ADDR>/ig; # Valgrind AMD64/Linux
data
s/[0-9]:[0-9]{2}:[0-9]{2}/<TIME>/g;
s/(.+)Time:(.*)seconds(.*)/<TIME>/g;
s/(.+)Rendering line(.*)/<TIME>/g; # Time (povray prints time
taken to execute)
s/Invalid read of.*/<MEMCHECK ERROR>/g; # povray has
multiple memcheck errors
s/Address .* bytes after a block .*/<MEMCHECK_ERROR>/g; # replace the
information with generic
# sizes and
addresses. Don't remove completely though
# as we'd still
like them to be around to catch errors
# in other tests
s/Total Alloc.*/<Allocation statistics>/g;
s/Peak memory.*/<Allocation statistics>/g;
s/kvasir-[\d.]+,/kvasir-VERSION/;
s[Using Valgrind-3.9.0.SVN and LibVEX; rerun with \-h for copyright
info]
[Using Valgrind and LibVEX; rerun with \-h for copyright info];
s/\(vg_replace_malloc.c:(\d+)\)/(vg_replace_malloc.c:XXX)/;
print;
}
-----Original Message-----
From: Nick Savoiu [mailto:sa...@ya...]
Sent: Friday, December 20, 2013 10:17 AM
To: val...@li...
Subject: [Valgrind-users] Making valgrind output diff-friendly
Hi all,
Valgrind's typical output
==19182== Invalid write of size 4
==19182== at 0x804838F: f (example.c:6)
==19182== by 0x80483AB: main (example.c:11)
==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd
==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
==19182== by 0x8048385: f (example.c:5)
==19182== by 0x80483AB: main (example.c:11)
is not very diff-friendly. Is there a way to suppress process id and address
printing? Perhaps something like
==?????== Invalid write of size 4
==?????== at 0x???????: f (example.c:6) ==?????== by 0x???????: main
(example.c:11) ==?????== Address 0x??????? is 0 bytes after a block of size
40 alloc'd ==?????== at 0x???????: malloc (vg_replace_malloc.c:130)
==?????== by 0x???????: f (example.c:5) ==?????== by 0x???????: main
(example.c:11)
or
==== Invalid write of size 4
==== at : f (example.c:6)
==== by : main (example.c:11)
==== Address is 0 bytes after a block of size 40 alloc'd ==== at :
malloc (vg_replace_malloc.c:130) ==== by : f (example.c:5) ==== by :
main (example.c:11)
Or is there a better way?
Thanks,
Nick
----------------------------------------------------------------------------
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Paul F. <pa...@fr...> - 2013-12-20 20:24:55
|
On 20 Dec 2013, at 19:16, Nick Savoiu wrote: > Hi all, > > Valgrind's typical output > > ==19182== Invalid write of size 4 > ==19182== at 0x804838F: f (example.c:6) > ==19182== by 0x80483AB: main (example.c:11) > ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd > ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) > ==19182== by 0x8048385: f (example.c:5) > ==19182== by 0x80483AB: main (example.c:11) > > is not very diff-friendly. Is there a way to suppress process id and address printing? Perhaps something like > > ==?????== Invalid write of size 4 > ==?????== at 0x???????: f (example.c:6) > ==?????== by 0x???????: main (example.c:11) > ==?????== Address 0x??????? is 0 bytes after a block of size 40 alloc'd > ==?????== at 0x???????: malloc (vg_replace_malloc.c:130) > ==?????== by 0x???????: f (example.c:5) > ==?????== by 0x???????: main (example.c:11) > > or > ==== Invalid write of size 4 > ==== at : f (example.c:6) > ==== by : main (example.c:11) > ==== Address is 0 bytes after a block of size 40 alloc'd > ==== at : malloc (vg_replace_malloc.c:130) > ==== by : f (example.c:5) > ==== by : main (example.c:11) Even this is not very diff-friendly (changing line numbers will cause diffs). I recommend enabling suppression generation (--gen-suppressions=yes). Then you can filter anything that isn't between braces. Or even simply use suppression file(s), in which case if there is a new or changed callstack you will get new errors. A+ Paul |
|
From: Philippe W. <phi...@sk...> - 2013-12-21 00:08:36
|
On Fri, 2013-12-20 at 21:24 +0100, Paul Floyd wrote: > Even this is not very diff-friendly (changing line numbers will cause diffs). > > I recommend enabling suppression generation (--gen-suppressions=yes). Then you can filter anything that isn't > between braces. Or even simply use suppression file(s), in which case if there is a new or changed callstack > you will get new errors. +1 for suppression files. Moreover, you can put comments in suppression files, e.g. explaining why the error reported by valgrind is to be ignored : E.g. reference a known bug, or explain why it is a false positive, or ... A diff file does not contain explanations. Philippe |
Thanks for helping keep SourceForge clean.
X