Created attachment 94215 [details] Valgrind output showing spurious errors Valgrind seems to be generating some false positives due to the implementation of libc on OS X 10.10, specifically the `printf` function. See the attachment for the relevant output of valgrind.
It's more likely that it's the implementation of memcpy that is the problem, given that we appear to be failing to intercept it and replace it with the internal, non-hyper-clever, version. Either that or you're passing uninitialised values to printf, but I assume you've checked that already ;-)
Yes, definitely not passing uninitialised values to printf. The printf itself is behaving correct (as you can see in the output file). It could well be memcpy, yes. Anything that’s internal to the printf function. > On 25 Aug 2015, at 17:13, Tom Hughes <tom@compton.nu> wrote: > > https://bugs.kde.org/show_bug.cgi?id=351756 > > Tom Hughes <tom@compton.nu> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |tom@compton.nu > > --- Comment #1 from Tom Hughes <tom@compton.nu> --- > It's more likely that it's the implementation of memcpy that is the problem, > given that we appear to be failing to intercept it and replace it with the > internal, non-hyper-clever, version. > > Either that or you're passing uninitialised values to printf, but I assume > you've checked that already ;-) > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug.
I'm pretty new to Valgrind, and in particular writing suppressions, but the following seems to do the trick for these errors. { OSX1010:_platform_memchr:cond Memcheck:Cond fun:_platform_memchr$VARIANT$Haswell } { OSX1010:_platform_memchr:addr Memcheck:Addr32 fun:_platform_memchr$VARIANT$Haswell } (Not sure about if the naming scheme is suitable for a patch, but you could fix that easily enough I suppose.)
Suppressing this is probably the wrong solution. I'm not sure why Rhys suggested that on the list - the correct answer is likely to be adding new interception patterns so that _platform_memchr$VARIANT$Haswell is trapped to our internal memchr variant. See shared/vg_replace_strmem.c for the details.
Basically, try this patch: Index: shared/vg_replace_strmem.c =================================================================== --- shared/vg_replace_strmem.c (revision 15566) +++ shared/vg_replace_strmem.c (working copy) @@ -891,6 +891,8 @@ MEMCHR(VG_Z_DYLD, memchr) /* _platform_memchr$VARIANT$Generic */ MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Generic) + /* _platform_memchr$VARIANT$Haswell */ + MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Haswell) # endif #elif defined(VGO_solaris)
That patch works well for me, thanks. (Are you going to commit it?)
Sorry, yes. That was my bad doing mailing list triage late at night. I can run it through the regression suite and commit.
Perfect. Thanks for the quick response and solution to this bug report.
Resolved in r15596. No regressions seen.