Bug 351756 - Intercept platform_memchr$VARIANT$Haswell on OS X
Summary: Intercept platform_memchr$VARIANT$Haswell on OS X
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: 3.10 SVN
Platform: Compiled Sources macOS
: NOR major
Target Milestone: ---
Assignee: Rhys Kidd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-25 16:03 UTC by Alexander Regueiro
Modified: 2015-08-29 07:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Valgrind output showing spurious errors (6.06 KB, text/plain)
2015-08-25 16:03 UTC, Alexander Regueiro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Regueiro 2015-08-25 16:03:28 UTC
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.
Comment 1 Tom Hughes 2015-08-25 16:13:39 UTC
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 ;-)
Comment 2 Alexander Regueiro 2015-08-25 16:36:01 UTC
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.
Comment 3 Alexander Regueiro 2015-08-26 14:10:34 UTC
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.)
Comment 4 Tom Hughes 2015-08-26 14:43:36 UTC
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.
Comment 5 Tom Hughes 2015-08-26 14:45:47 UTC
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)
Comment 6 Alexander Regueiro 2015-08-26 16:19:43 UTC
That patch works well for me, thanks. (Are you going to commit it?)
Comment 7 Rhys Kidd 2015-08-27 02:20:46 UTC
Sorry, yes. That was my bad doing mailing list triage late at night.

I can run it through the regression suite and commit.
Comment 8 Alexander Regueiro 2015-08-27 12:50:14 UTC
Perfect. Thanks for the quick response and solution to this bug report.
Comment 9 Rhys Kidd 2015-08-29 07:43:26 UTC
Resolved in r15596.
No regressions seen.