Thanks John!
The libc shared library does not seem to mention any version number. I'm on
MacOs 10.6.8 on Intel. How do I get the version of libc?Here's what I get from
valgrind -v:
---------------------------------------------------------==57528== Memcheck, a
memory error detector==57528== Copyright (C) 2002-2011, and GNU GPL'd, by
Julian Seward et al.==57528== Using Valgrind-3.7.0 and LibVEX; rerun with -h
for copyright info==57528== Command: ./check==57528== --57528-- Valgrind
options:--57528-- -v--57528-- --dsymutil=yes--57528-- Contents of
/proc/version:--57528-- can't open /proc/version--57528-- Arch and hwcaps:
AMD64, amd64-sse3-cx16--57528-- Page sizes: currently 4096, max supported
4096--57528-- Valgrind library directory:
/Users/tan/Tools/valgrind/install_dir/lib/valgrind--57528-- ./check
(0x100000000)--57528-- reading syms from primary file (7 4)--57528-- run:
/usr/bin/dsymutil "./check"warning: no debug symbols in executable (-arch
x86_64)--57528-- dsyms= ./check.dSYM/Contents/Resources/DWARF/check--57528--
/usr/lib/dyld (0x7fff5fc00000)--57528-- reading syms from primary file (6
1186)--57528-- Reading suppressions file:
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/default.supp==57528==
embedded gdbserver: reading from
/var/folders/In/In0K1bIIGmOe2IoRTx-hcE+++TM/-Tmp-//vgdb-pipe-from-vgdb-to-57528-by-tan-on-???==57528==
embedded gdbserver: writing to
/var/folders/In/In0K1bIIGmOe2IoRTx-hcE+++TM/-Tmp-//vgdb-pipe-to-vgdb-from-57528-by-tan-on-???==57528==
embedded gdbserver: shared mem
/var/folders/In/In0K1bIIGmOe2IoRTx-hcE+++TM/-Tmp-//vgdb-pipe-shared-mem-vgdb-57528-by-tan-on-???==57528==
==57528== TO CONTROL THIS PROCESS USING vgdb (which you probably==57528==
don't want to do, unless you know exactly what you're doing,==57528== or are
doing some strange experiment):==57528==
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/../../bin/vgdb --pid=57528
...command...==57528== ==57528== TO DEBUG THIS PROCESS USING GDB: start GDB
like this==57528== /path/to/gdb ./check==57528== and then give GDB the
following command==57528== target remote |
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/../../bin/vgdb
--pid=57528==57528== --pid is optional if only one valgrind process is
running==57528== --57528-- REDIR: 0x7fff5fc22fb0 (strcmp) redirected to
0x13804cb90 (???)--57528-- REDIR: 0x7fff5fc20693 (arc4random) redirected to
0x13804cc2e (???)--57528-- REDIR: 0x7fff5fc22e90 (strlen) redirected to
0x13804cb5f (???)--57528-- REDIR: 0x7fff5fc22ee0 (strcpy) redirected to
0x13804cbac (???)--57528-- REDIR: 0x7fff5fc2306f (strcat) redirected to
0x13804cb70 (???)--57528--
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_core-amd64-darwin.so
(0x100004000)--57528-- reading syms from primary file (3 135)--57528--
dSYM=
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_core-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_core-amd64-darwin.so--57528--
reading dwarf3 from dsyms file--57528--
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_memcheck-amd64-darwin.so
(0x10000f000)--57528-- reading syms from primary file (32 273)--57528--
dSYM=
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_memcheck-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_memcheck-amd64-darwin.so--57528--
reading dwarf3 from dsyms file--57528-- /usr/lib/libSystem.B.dylib
(0x10001d000)--57528-- reading syms from primary file (4606 3793)--57528--
REDIR: 0x10001deb4 (memset) redirected to 0x100010c80 (memset)--57528-- REDIR:
0x10001fc5c (malloc) redirected to 0x1000105f7 (malloc)--57528-- REDIR:
0x100020bf0 (strlen) redirected to 0x100010af0 (strlen)--57528-- REDIR:
0x100020280 (strncmp) redirected to 0x100010be0
(strncmp)sizeof(mvk_lruc_kv_t)=152, 0x1002772f0, 0x100277388, 0x100277420,
0x1002770e0at index 0end at index 0at index 1==57528== Invalid read of size
8==57528== at 0x7FFFFFE00BAC: ???==57528== by 0x100000E4D:
__inline_memcpy_chk (in ./check)==57528== by 0x100000DCF: main (in
./check)==57528== Address 0x1002772a8 is 0 bytes after a block of size 456
alloc'd==57528== at 0x100010679: malloc (vg_replace_malloc.c:266)==57528==
by 0x100000CC5: main (in ./check)==57528== end at index 1at index 2end at
index 2at index 3-------------------------- some more similar printf outputs
pruned here --------------------------------at index 26end at index 26==57528==
==57528== HEAP SUMMARY:==57528== in use at exit: 9,200 bytes in 4
blocks==57528== total heap usage: 4 allocs, 0 frees, 9,200 bytes
allocated==57528== ==57528== Searching for pointers to 4 not-freed
blocks==57528== Checked 415,728 bytes==57528== ==57528== LEAK SUMMARY:==57528==
definitely lost: 5,016 bytes in 2 blocks==57528== indirectly lost: 0
bytes in 0 blocks==57528== possibly lost: 0 bytes in 0 blocks==57528==
still reachable: 4,096 bytes in 1 blocks==57528== suppressed: 88 bytes
in 1 blocks==57528== Rerun with --leak-check=full to see details of leaked
memory==57528== ==57528== ERROR SUMMARY: 13 errors from 1 contexts (suppressed:
0 from 0)==57528== ==57528== 13 errors in context 1 of 1:==57528== Invalid read
of size 8==57528== at 0x7FFFFFE00BAC: ???==57528== by 0x100000E4D:
__inline_memcpy_chk (in ./check)==57528== by 0x100000DCF: main (in
./check)==57528== Address 0x1002772a8 is 0 bytes after a block of size 456
alloc'd==57528== at 0x100010679: malloc (vg_replace_malloc.c:266)==57528==
by 0x100000CC5: main (in ./check)==57528== --57528-- --57528--
used_suppression: 1 libSystem-keymgr-leak-at-exit==57528== ==57528== ERROR
SUMMARY: 13 errors from 1 contexts (suppressed: 0 from 0)
---------------------------------------------------------------------------------
> Date: Fri, 6 Jul 2012 08:16:33 -0700
> From: [email protected]
> To: [email protected]
> Subject: Re: [Valgrind-users] Strange warning for invalid read of size 8 in
> memcpy
>
> > I'm getting an invalid read of size 8 warning with the code (check.c) below.
> > Everything seems to be fine, and the warning about reading beyond the
> > allocated source pointer comes only when I'm copying the source to a
> > particular index of the destination.
> >
>
> Please copy+paste the exact error message and traceback. The pc matters:
> your program, memcheck's interceptor, or un-intercepted libc instructions.
> Also, the addresses matter: the low-order 5 bits of each of the source,
> destination, and length.
>
> > My environment:
> > - MacOSX Darwin 10.8.0 Darwin Kernel Version 10.8.0
> > - valgrind-3.7.0
> > - gcc version: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build
> > 5666) (dot 3)
>
> Thank you for reporting those versions! Also, which version of libc are you
> using?
>
> Re-run with "valgrind -v ./check". Check the suppressions file
> --1658-- Reading suppressions file: /usr/lib64/valgrind/default.supp
> to see which mem* reports are being suppressed, and by which version of
> the suppressions master file(s).
> Pay particular attention to all REDIR which refer to mem* functions:
> --1658-- REDIR: 0x363b88e690 (memcpy@@GLIBC_2.14) redirected to 0x4802700
> (_vgnU_ifunc_wrapper)
> --1658-- REDIR: 0x363b944b40 (__memcpy_ssse3_back) redirected to 0x4a09ff0
> (memcpy@@GLIBC_2.14)
>
> memcheck gives me no complaints when running your check.c on Fedora 17:
> Linux host.domain 3.4.3-1.fc17.x86_64 #1 SMP Mon Jun 18 19:53:17 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
> Using Valgrind-3.7.0
> gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
> glibc-2.15-37.fc17.x86_64
>
> --
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
