Sorry, my bad - I did get this to work - I was using the old header file
with the new valgrind.
Anupam
On Thu, Apr 5, 2012 at 10:50 AM, Anupam Prabhakar <[email protected]
> wrote:
> Hi,
>
> I installed the latest version of valgrind 3.7.0 (I was using 3.1.1
> before). The newer version of valgrind is not reporting Invalid read/write
> etc. Is there something obvious that you can think of ? Do you think I
> not install it correctly ?
>
> Anupam
>
> This is head of the log from 3.7.0
> ==4873== Memcheck, a memory error detector
> ==4873== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==4873== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==4873== Command: vsimk -c test -do run\ -all -valgrind
> ==4873== Parent PID: 16899
> ==4873==
> --4873--
> --4873-- Valgrind options:
> --4873-- -v
> --4873-- --log-file=v1.log
> --4873-- --leak-check=full
> --4873-- --show-reachable=yes
> --4873-- Contents of /proc/version:
> --4873-- Linux version 2.6.9-67.ELsmp (
> [email protected]) (gcc version 3.4.6 20060404 (Red
> Hat 3.4.6-8)) #1 SMP Wed Nov 7 13:56:44 EST 2007
> --4873-- Arch and hwcaps: X86, x86-sse1-sse2
> --4873-- Page sizes: currently 4096, max supported 4096
> --4873-- Valgrind library directory: /usr/valgrind-3.7.0/lib/valgrind
> --4873-- Reading syms from /lib/ld-2.3.4.so (0x5f3000)
> --4873-- Reading syms from /home/anupamp/install/linux/vsimk (0x8048000)
> --4873-- warning: DiCfSI 0x0 .. 0x3 outside segment 0x80625c0 .. 0x8dedc7b
> --4873-- warning: DiCfSI 0x0 .. 0x3 outside segment 0x80625c0 .. 0x8dedc7b
> --4873-- warning: DiCfSI 0x0 .. 0x3 outside segment 0x80625c0 .. 0x8dedc7b
> --4873-- warning: DiCfSI 0x0 .. 0x3 outside segment 0x80625c0 .. 0x8dedc7b
> --4873-- Reading syms from
> /usr/valgrind-3.7.0/lib/valgrind/memcheck-x86-linux (0x38000000)
> --4873-- object doesn't have a dynamic symbol table
> --4873-- Reading suppressions file:
> /usr/valgrind-3.7.0/lib/valgrind/default.supp
> ==4873== embedded gdbserver: reading from
> /tmp/vgdb-pipe-from-vgdb-to-4873-by-anupamp-on-dvtvnc8
> ==4873== embedded gdbserver: writing to
> /tmp/vgdb-pipe-to-vgdb-from-4873-by-anupamp-on-dvtvnc8
> ==4873== embedded gdbserver: shared mem
> /tmp/vgdb-pipe-shared-mem-vgdb-4873-by-anupamp-on-dvtvnc8
> ==4873==
> ==4873== TO CONTROL THIS PROCESS USING vgdb (which you probably
> ==4873== don't want to do, unless you know exactly what you're doing,
> ==4873== or are doing some strange experiment):
> ==4873== /usr/valgrind-3.7.0/lib/valgrind/../../bin/vgdb --pid=4873
> ...command...
> ==4873==
> ==4873== TO DEBUG THIS PROCESS USING GDB: start GDB like this
> ==4873== /path/to/gdb vsimk
> ==4873== and then give GDB the following command
> ==4873== target remote | /usr/valgrind-3.7.0/lib/valgrind/../../bin/vgdb
> --pid=4873
> ==4873== --pid is optional if only one valgrind process is running
>
>
> This is from 3.1.1
> ==1678== Memcheck, a memory error detector.
> ==1678== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
> ==1678== Using LibVEX rev 1575, a library for dynamic binary translation.
> ==1678== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==1678== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
> ==1678== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
> ==1678==
> ==1678== My PID = 1678, parent PID = 16899. Prog and args are:
> ==1678== vsimk
> ==1678== -c
> ==1678== test
> ==1678== -do
> ==1678== run -all
> ==1678== -valgrind
> ==1678==
> --1678--
> --1678-- Command line
> --1678-- vsimk
> --1678-- -c
> --1678-- test
> --1678-- -do
> --1678-- run -all
> --1678-- -valgrind
> --1678-- Startup, with flags:
> --1678-- -v
> --1678-- --log-file=v1.log
> --1678-- --leak-check=full
> --1678-- --show-reachable=yes
> --1678-- Contents of /proc/version:
> --1678-- Linux version 2.6.9-67.ELsmp (
> [email protected]) (gcc version 3.4.6 20060404 (Red
> Hat 3.4.6-8)) #1 SMP Wed Nov 7 13:56:44 EST 2007
> --1678-- Arch and subarch: X86, x86-sse2
> --1678-- Valgrind library directory: /usr/lib/valgrind
> --1678-- Reading syms from /lib/ld-2.3.4.so (0x5F3000)
> --1678-- Reading syms from /home/anupamp/install/linux/vsimk (0x8048000)
> --1678-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --1678-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --1678-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --1678-- DWARF2 CFI reader: unhandled CFI instruction 0:10
> --1678-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck
> (0xB0000000)
> --1678-- object doesn't have a dynamic symbol table
> --1678-- Reading suppressions file: /usr/lib/valgrind/default.supp
> --1678-- REDIR: 0x6055B0 (index) redirected to 0xB001BC86
> (vgPlain_x86_linux_REDIR_FOR_index)
> --1678-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so
> (0x5BA6000)
> --1678-- Reading syms from
> /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x5BCD000)
> --1678-- REDIR: 0x605750 (strlen) redirected to 0x5BCFE90 (strlen)
> --1678-- Reading syms from /lib/tls/libpthread-2.3.4.so (0x844000)
> --1678-- Reading syms from /lib/libdl-2.3.4.so (0x740000)
> --1678-- Reading syms from /lib/tls/libm-2.3.4.so (0x746000)
> --1678-- Reading syms from /lib/tls/librt-2.3.4.so (0x5C94000)
> --1678-- Reading syms from /lib/tls/libc-2.3.4.so (0x612000)
>
>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
