Question: What is [shared pmap]? / False positive?

[real-or-random]

I guess this is more of a question than an issue. The following is from the failure was trying to debug (now with a useful stack strace after #125 merged!):

==22464== Conditional jump or move depends on uninitialised value(s)
==22464==    at 0x7FF801C18587: ??? (in /dev/macos/internals/[shared pmap])
==22464==    by 0x100000690: label_lookup (silentpayments.c:104)
==22464==    by 0x1000217D8: secp256k1_silentpayments_recipient_scan_outputs (main_impl.h:575)
==22464==    by 0x100000C4D: main (silentpayments.c:386)
==22464==  Uninitialised value was created by a stack allocation
==22464==    at 0x100020ACD: secp256k1_silentpayments_recipient_scan_outputs (main_impl.h:477)

This line of code in label_lookup is a call to memcmp (which, I assume from the above, has been optimized by the compiler?). I know _internal_memcmp is redirect but it does not appear here.

I tried VALGRIND_CHECK_MEM_IS_DEFINED and it confirms that all bytes in both arguments of the call are defined. So this looks like a false positive?! But to be honest, I have no idea what [shared pmap] is? I'd appreciate any ideas or pointers, but also feel free to close this as not really actionable (unless we want to add a suppression?)

[LouisBrunner]

This is a bit of a complex one because a lot of things are coming together at the same time.

What is /dev/macos/internals/[shared pmap]?

As part of the work for arm64, I needed a lot of debugging information, so I tried to get as much data out of macOS as I could. This path is a fake path introduced as part of this for memory regions without any name. In previous versions of Valgrind, you would just see

==22464==    at 0x7FF801C18587: ??? (in ???)

This name is determined through the kernel's mach_vm_region_recurse API. This is the same thing vmmap does when you run it against a binary and it says something like MALLOC guard page. You can find all potential paths and their vm tag equivalent here:

valgrind-macos/coregrind/m_aspacemgr/aspacemgr-linux.c

Line 3805 in 5d88e07

static Bool get_name_from_tag(int tag, HChar* path, SizeT path_len) {

But what does it actually mean? From the context and your expectations of memcmp, it is the part of the memory where the DYLD cache is loaded by the kernel.

Why does this show an error?

At start, we load a few dyld explicitly to ensure important symbols (especially for malloc) are loaded by Valgrind, the rest are loaded by the client binary itself. This is important because Valgrind relies on symbol names to replace calls to a lot of functions (called redirections internally).

As many of those core libc functions (like memcmp) rely on intrinsics and other vectorized tricks for performance (I am not super familiar with the details), they do tend to show a lot of false positives (as they seemingly load memory that's not been initialized).

Unfortunately, it seems that the symbol is not loaded at all. This is usually an issue with the symbol itself being missing from DYLD cache, or it could be a Valgrind bug. Otherwise, memcmp would be replaced by the Valgrind version.

How do we fix this?

If you are positive that the memory is defined, then it's most likely a false positive from the optimized code from the system memcmp.

Which architecture/macOS version is this?
I know you have been running Valgrind on amd64 without issue for a while, so if this is happening on there, then it seems like it would a regression, potentially from the (unfortunately extensive) arm64 changes.
If this is arm64, then it's a symbol loading issue or potentially a new entrypoint into memcmp that Valgrind isn't expecting.