Big Sur (macOS 11.0) compatibility

[ncovercash]

Latest version of the repo and tap fails to compile on Big Sur with the following error:

configure: error: Valgrind works on Darwin 10.x-19.x (Mac OS X 10.6-11 and macOS 10.12-15)

[DiegoMagdaleno]

• 1 on this issue, even after fixing that it won't compile.

[MattiaMontanari]

+1

[LouisBrunner]

I just pushed a fix on master which allows you to run valgrind (I tested it with Python3 and it seems to work correctly).
Note this implementation is a stop-gap and highly experimental, it might break/give incorrect results easily (I think debug information will be pretty lacking in general, e.g. missing symbol names in stack traces).

[Nimon77]

I just download the new version and like you just say, it doesn't work

❯ cat test.c
#include <stdlib.h>

int main(int argc, const char *argv[])
{
	char *test;

	test = malloc(3);
	test = malloc(5);
	return 0;
}

❯ gcc test.c -g

❯ valgrind ./a.out
==48623== Memcheck, a memory error detector
==48623== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==48623== Using Valgrind-3.17.0.GIT-lbmacos and LibVEX; rerun with -h for copyright info
==48623== Command: ./a.out
==48623==
==48623== Warning: set address range perms: large range [0x7fff20002000, 0x80001fe02000) (defined)
==48623== Warning: set address range perms: large range [0x7fff20002000, 0x7fff7ffc2000) (defined)
==48623== Warning: set address range perms: large range [0x7fff8e57a000, 0x7fffc0002000) (noaccess)
==48623== Warning: set address range perms: large range [0x7fffc0002000, 0x7fffe1cea000) (defined)
==48623== Warning: set address range perms: large range [0x7fffe1cea000, 0x7fffffe00000) (noaccess)
==48623==
==48623== HEAP SUMMARY:
==48623==     in use at exit: 0 bytes in 0 blocks
==48623==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==48623==
==48623== All heap blocks were freed -- no leaks are possible
==48623==
==48623== For lists of detected and suppressed errors, rerun with: -s
==48623== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[LouisBrunner]

Yeah, we need more granular ranges on the task shared memory. Uninitialized values/jump still work though.

[karimvafin]

Hello, I installed valgrind from your repo, but it doesn't detect any allocs and frees (although I'm sure there should be about 100,000 of them). macOS 11 Big Sur. What could be the problem? TY

[LouisBrunner]

@karimvafin, as reported above, Big Sur support is experimental and leak-tracking doesn't work at the moment.

[LouisBrunner]

Just wanted to share a quick progress update, I have now replicated dyld's cache loading logic and can retrieve dylibs from the cache. dyld uses stat64 to check if a library is on disk before checking into the cache, so I use this as a hint (if they fail and the path look like a lib) and then check the cache myself.

I am now running into the following issues:

• Valgrind is heavily geared around loading Mach-O (or any format really) files from disk and thus I have to heavily alter the debuginfo component to allow me to load from memory
• I am still fuzzy on where/how __DATA is mapped when dyld uses the cache, thus unable to replicate it in Valgrind
• Valgrind has warnings against mmaping big chunks of memory but if I don't do that, I need to manually mark anything dyld is likely to read as accessible otherwise it throws ~3k errors, so either I disable the warnings when mmap-ing the dyld cache or I do it super granularly but I'll miss a lot of chunks and some warnings will slip through

Overall, I am pretty confident supporting the cache is doable (if I can resolve the __DATA, big unknown!) and shouldn't take a massive amount of time (I don't want to promise this year, but I'll try my best).

P.S.: Paul Floyd confirmed that the missing leak tracking is also due to that issue, so hopefully Valgrind should be back to normal once this is fixed.

[rex4539]

% valgrind ls -l     
==99784== Memcheck, a memory error detector
==99784== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==99784== Using Valgrind-3.17.0.GIT-lbmacos and LibVEX; rerun with -h for copyright info
==99784== Command: ls -l
==99784== 
==99784== Invalid read of size 8
==99784==    at 0x10006A166: cerror_nocancel (in /usr/lib/dyld)
==99784==    by 0x10006A6ED: kdebug_is_enabled (in /usr/lib/dyld)
==99784==    by 0x100023467: dyld3::kdebug_trace_dyld_marker(unsigned int, dyld3::kt_arg, dyld3::kt_arg, dyld3::kt_arg, dyld3::kt_arg) (in /usr/lib/dyld)
==99784==    by 0x1000110C8: dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) (in /usr/lib/dyld)
==99784==    by 0x100011024: _dyld_start (in /usr/lib/dyld)
==99784==    by 0x1: ???
==99784==    by 0x10492723A: ???
==99784==    by 0x10492723D: ???
==99784==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==99784== 
==99784== 
==99784== Process terminating with default action of signal 11 (SIGSEGV)
==99784==  Access not within mapped region at address 0x8
==99784==    at 0x10006A166: cerror_nocancel (in /usr/lib/dyld)
==99784==    by 0x10006A6ED: kdebug_is_enabled (in /usr/lib/dyld)
==99784==    by 0x100023467: dyld3::kdebug_trace_dyld_marker(unsigned int, dyld3::kt_arg, dyld3::kt_arg, dyld3::kt_arg, dyld3::kt_arg) (in /usr/lib/dyld)
==99784==    by 0x1000110C8: dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) (in /usr/lib/dyld)
==99784==    by 0x100011024: _dyld_start (in /usr/lib/dyld)
==99784==    by 0x1: ???
==99784==    by 0x10492723A: ???
==99784==    by 0x10492723D: ???
==99784==  If you believe this happened as a result of a stack
==99784==  overflow in your program's main thread (unlikely but
==99784==  possible), you can try to increase the size of the
==99784==  main thread stack using the --main-stacksize= flag.
==99784==  The main thread stack size used in this run was 8388608.
==99784== 
==99784== HEAP SUMMARY:
==99784==     in use at exit: 0 bytes in 0 blocks
==99784==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==99784== 
==99784== All heap blocks were freed -- no leaks are possible
==99784== 
==99784== For lists of detected and suppressed errors, rerun with: -s
==99784== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
zsh: segmentation fault  valgrind ls -l

[yaozhang-this]

Is Official Valgrind still in the loop? I have tried contacting the dev members on the website to see their plan on MacOS update and the email turned out null.