> I think there's a difference in the environment. > > For me: > About This Mac > More Info... > System Report... > Software > Developer: > Version:3.2 (10M2518)
> Xcode:3.2.6 (1761) > SDKs: > Mac OS X: > 10.5:(9L31a) > 10.6:(10M2518) > > and for you memcpy is redirected differently: >> --24112-- REDIR: 0x10015bcbd (memcpy$VARIANT$sse42) redirected to >> 0x100010ed0 (memmove$VARIANT$sse42) > In any case... pardon my questions... I'm still a newbie in this. > But can you please explain the discussions between you and Pat? Pat points out that sometimes valgrind does not understand various "idioms" (arcane sequences of instructions) used by the compiler and/or runtime system. In particular, there is a long and convoluted history of "word at a time" idioms (instead of simple "character at a time" code) for computing strlen() and strchr(). Such idioms are part of the reason for valgrind's REDIR mechanism. When it works (and usually it does), then the REDIR mechanism makes it possible for memcheck to ignore the hard-to-understand code, and skip the instruction-by-instruction interpretation, of many str*() and mem*() routines. When REDIR does not work (and the bugs have been numerous) then confusion reigns. SSE4.1 introduced some new instructions which enable strlen/strchr to process 16 bytes at a time. Tracking these is even harder than the word-at-a-time idioms. Because one of the instructions always fetches 16 bytes, then naively it looks like that instruction often fetches beyond the end of an allocated block. But correct usage eventually ignores the bytes that are "over fetched", so there is no actual problem at the level of the whole idiom. Understanding the idiom involves understanding a 16-byte fetch. See below for why this can be tricky. The optimizations for memcpy do not involve SSE4.1, and the occurrence of over-fetching by memcpy is very much less than for strlen/strchr. I suspect that memcpy can over-fetch by at most 3 bytes (using a 4-byte fetch), so memcpy should not draw any complaints involving 8-byte fetches. In general --partial-loads-ok=yes silences memcheck even though memcheck would otherwise complain about overfetching. I suspect it's not the real problem in your case. > In particular... > - Why would memcpy need to read 8 bytes more? Although your memcheck run claims that memcpy is reading 8 bytes more, it isn't clear whether memcpy actually is reading 8 bytes more. The complaint could be part of a manifestation of a bug (or a couple of bugs) in memcheck. We've already pointed out that your run has no REDIR of memcpy when it should, so that is a problem of some kind. The REDIR machinery has failed. Part of the failure could be due to the actual symbolic name(s) that the compiler and runtime system have used for "memcpy". We need to see the actual code that is being executed. In particular, you haven't shown the code which surrounds 0x7FFFFFE00BAC from your initial report: ==57528== Invalid read of size 8 ==57528== at 0x7FFFFFE00BAC: ??? ==57528== by 0x100000E4D: __inline_memcpy_chk (in ./check) Please produce a disassembly of __inline_memcpy_chk that surrounds address 0x100000E4D. Please produce a disassembly of the routine that __inline_memcpy_chk calls (probably surrounding 0x7FFFFFE00BAC). Valgrind has a history that is more than ten years long. In the beginning, the only memory transfers that valgrind tracked were 1,2,4, or 8 bytes wide. Then came SSE and SSE2, which have some 16-byte transfers. Until valgrind implemented the internal machinery to track 16-byte transfers, there was an interim use of two 8-byte transfers. Keeping track of all of the associations between two 8-byte transfers is harder than keeping track of all of the associations of one 16-byte transfer. This might be involved in the specific complaint that you get. > - And why would the warning depend on the destination? That is, why am I > getting this only in the 2nd iteration and not any other time? The first iteration might be special because the dynamic linkage is resolved on the first reference from any particular CALL, but not on subsequent references from the same CALL. The third and following references might actually be producing the same error, but because the traceback is the same as the error produced by the second call, then memcheck might process the "same error" by just incrementing a count associated with the traceback, instead of printing the full message each time. Because my effort failed to reproduce the bad behavior that you see, then the response to a bug report may well be "upgrade your XCode/Developer". Unless there is a good reason for insisting on fixing the interaction of valgrind with old versions of Apple code, then "upgrade to current version" (especially when the upgrade costs no money) is reasonable. [By the way, please trim more aggressively when responding. Most of what you quoted wasn't relevant to your response.] -- ------------------------------------------------------------------------------ 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
