Thanks John and Pat.
So what I understand is I can ignore the warning in this case.But, I still get
the warning even with --partial-loads-ok=yes. Why so?
- Tan
Below is the output with
--partial-loads-ok=yes:--------------------------------------------------------------------------------==67529==
Memcheck, a memory error detector==67529== Copyright (C) 2002-2011, and GNU
GPL'd, by Julian Seward et al.==67529== Using Valgrind-3.7.0 and LibVEX; rerun
with -h for copyright info==67529== Command: ./check==67529== --67529--
Valgrind options:--67529-- -v--67529-- --dsymutil=yes--67529--
--partial-loads-ok=yes--67529-- Contents of /proc/version:--67529-- can't
open /proc/version--67529-- Arch and hwcaps: AMD64, amd64-sse3-cx16--67529--
Page sizes: currently 4096, max supported 4096--67529-- Valgrind library
directory: /Users/tan/Tools/valgrind/install_dir/lib/valgrind--67529-- ./check
(0x100000000)--67529-- reading syms from primary file (7 4)--67529--
dSYM= ./check.dSYM/Contents/Resources/DWARF/check--67529-- /usr/lib/dyld
(0x7fff5fc00000)--67529-- reading syms from primary file (6 1186)--67529--
Reading suppressions file:
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/default.supp==67529==
embedded gdbserver: reading from
/var/folders/In/In0K1bIIGmOe2IoRTx-hcE+++TM/-Tmp-//vgdb-pipe-from-vgdb-to-67529-by-tan-on-???==67529==
embedded gdbserver: writing to
/var/folders/In/In0K1bIIGmOe2IoRTx-hcE+++TM/-Tmp-//vgdb-pipe-to-vgdb-from-67529-by-tan-on-???==67529==
embedded gdbserver: shared mem
/var/folders/In/In0K1bIIGmOe2IoRTx-hcE+++TM/-Tmp-//vgdb-pipe-shared-mem-vgdb-67529-by-tan-on-???==67529==
==67529== TO CONTROL THIS PROCESS USING vgdb (which you probably==67529==
don't want to do, unless you know exactly what you're doing,==67529== or are
doing some strange experiment):==67529==
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/../../bin/vgdb --pid=67529
...command...==67529== ==67529== TO DEBUG THIS PROCESS USING GDB: start GDB
like this==67529== /path/to/gdb ./check==67529== and then give GDB the
following command==67529== target remote |
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/../../bin/vgdb
--pid=67529==67529== --pid is optional if only one valgrind process is
running==67529== --67529-- REDIR: 0x7fff5fc22fb0 (strcmp) redirected to
0x13804cb90 (???)--67529-- REDIR: 0x7fff5fc20693 (arc4random) redirected to
0x13804cc2e (???)--67529-- REDIR: 0x7fff5fc22e90 (strlen) redirected to
0x13804cb5f (???)--67529-- REDIR: 0x7fff5fc22ee0 (strcpy) redirected to
0x13804cbac (???)--67529-- REDIR: 0x7fff5fc2306f (strcat) redirected to
0x13804cb70 (???)--67529--
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_core-amd64-darwin.so
(0x100004000)--67529-- reading syms from primary file (3 135)--67529--
dSYM=
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_core-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_core-amd64-darwin.so--67529--
reading dwarf3 from dsyms file--67529--
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_memcheck-amd64-darwin.so
(0x10000f000)--67529-- reading syms from primary file (32 273)--67529--
dSYM=
/Users/tan/Tools/valgrind/install_dir/lib/valgrind/vgpreload_memcheck-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_memcheck-amd64-darwin.so--67529--
reading dwarf3 from dsyms file--67529-- /usr/lib/libSystem.B.dylib
(0x10001d000)--67529-- reading syms from primary file (4606 3793)--67529--
REDIR: 0x10001deb4 (memset) redirected to 0x100010c80 (memset)--67529-- REDIR:
0x10001fc5c (malloc) redirected to 0x1000105f7 (malloc)--67529-- REDIR:
0x100020bf0 (strlen) redirected to 0x100010af0 (strlen)--67529-- REDIR:
0x100020280 (strncmp) redirected to 0x100010be0
(strncmp)sizeof(mvk_lruc_kv_t)=152, 0x1002772f0, 0x100277388, 0x100277420,
0x1002770e0at index 0end at index 0at index 1==67529== Invalid read of size
8==67529== at 0x7FFFFFE00BAC: ???==67529== by 0x100000E4D:
__inline_memcpy_chk (in ./check)==67529== by 0x100000DCF: main (in
./check)==67529== Address 0x1002772a8 is 0 bytes after a block of size 456
alloc'd==67529== at 0x100010679: malloc (vg_replace_malloc.c:266)==67529==
by 0x100000CC5: main (in ./check)==67529== end at index
1.....--------------------------------------------------------------------------------
> Date: Fri, 6 Jul 2012 17:27:29 -0700
> From: [email protected]
> To: [email protected]
> Subject: Re: [Valgrind-users] Strange warning for invalid read of size 8 in
> memcpy
>
> On 07/06/2012 03:37 PM, Patrick J. LoPresti wrote:
> > On Fri, Jul 6, 2012 at 11:45 AM, John Reiser <[email protected]> wrote:
> >>
> >> The compiler has decided to generate inline code for memcpy.
> >> This is hard for memcheck to recognize as memcpy.
> >
> > But memcheck does not have to recognize it at all if you use
> > "--partial-loads-ok=yes".
> >
> > The problem is that the default memory model in memcheck does not
> > reflect the way modern machines (and compilers) work. The inlined
> > memcpy() is reading undefined data past the end of an allocated block,
> > but it is doing so with an aligned load and it is not propagating the
> > undefined data further. So the code is perfectly valid and memcheck's
> > error report is simply wrong.
> >
> > The good news is that you can fix memcheck's memory model by
> > specifying "--partial-loads-ok=yes". (As I have said before, I am of
> > the opinion that this quite obviously should be the default.) The bad
> > news is that (a) it is broken for SSE loads
> > (https://bugs.kde.org/show_bug.cgi?id=294285) and (b) memcheck's
> > validity bit propagation may be insufficiently precise to suppress the
> > false positive.
>
> In general it may be true that --partial-loads-ok=yes is a better default.
>
> However in this case, something else looks like a bigger culprit, and the
> use of --partial-loads-ok=yes as default results in a substantial performance
> penalty, as well as less error checking by memcheck.
>
> The bigger culprit is that some portions of Mac OS X 10.8.0, in particular
> some portions of XCode 4.3.2 (4E2002), have changed the name from 'memcpy_chk'
> to '__memcpy_chk', and from 'inline_memcpy_chk' to '__inline_memcpy_chk'.
> [In the Debug style of XCode, the "inline" are actual out-of-line
> subroutines.] The use of the double underscore prefix prevents
> memcheck's usual redirection of those routines. The memcheck source
> code needs to be enhanced to recognize the new names as well as the old.
>
> Because __memcpy_chk and __inline_memcpy_chk are not intercepted as whole
> routines, then memcheck must emulate them instruction-by-instruction.
> This is slow, and omits the checks for overlapping ranges. (These OS X
> libsystem_c.dylib *_chk routines check for stack smashing, but not for
> overlap of source and destination.)
>
> --
>
>
> ------------------------------------------------------------------------------
> 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
