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
