valgrind-macos
valgrind-macos copied to clipboard
LouisBrunner
Big Sur (macOS 11.0) compatibility
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)
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).
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)
Yeah, we need more granular ranges on the task shared memory. Uninitialized values/jump still work though.
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
@karimvafin, as reported above, Big Sur support is experimental and leak-tracking doesn't work at the moment.
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
debuginfocomponent to allow me to load from memory - I am still fuzzy on where/how
__DATAis 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.
% 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
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.
% brew upgrade
==> Upgrading 1 outdated package:
valgrind 3.13.0 -> 3.16.1
==> Upgrading valgrind 3.13.0 -> 3.16.1
valgrind: Linux is required for this software.
Error: valgrind: An unsatisfied requirement failed this build.
% brew --version
Homebrew 2.7.3
Homebrew/homebrew-core (git revision 8b7e0; last commit 2021-01-12)
Homebrew/homebrew-cask (git revision cc6bf; last commit 2021-01-12)
% uname -prsv
Darwin 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec 2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 i386
@Gamusren A few devs are aware of this fork, I haven't tried to get it merged upstream in a while (often the issue is that too many regression tests fail). You can contact them through their mailing list or Bugzilla.
@dholmes-epcc-ed-ac-uk ???
Sorry for the lack of update, I haven't had time to sit down and work much on Big Sur compatibility lately. A lot of the time when working on macOS support, the difficulty for me is more around understanding what Valgrind is doing and what/why/how macOS has changed. In this case, Valgrind needs to support a whole new system which means changing some of the design/architecture, writing a lot more code and more uncertainties in general. This takes a lot of effort and I haven't had the time or energy to dedicate to it lately. I haven't forgotten about it and do plan to finish it at some point though!
Is there any alternative on MacOS whilst we wait for this fix? Thanks
leaks is all I know of.
➜ cat test.c
#include <stdlib.h>
int main(int argc, char const *argv[])
{
int *test;
test = malloc(2);
test = malloc(2);
return 0;
}
➜ leaks --atExit -- ./test
Process: test [53270]
Path: /Users/USER/*/test
Load Address: 0x1012eb000
Identifier: test
Version: ???
Code Type: X86-64
Platform: macOS
Parent Process: leaks [53269]
Date/Time: 2021-02-22 21:01:09.947 -0500
Launch Time: 2021-02-22 21:01:09.842 -0500
OS Version: macOS 11.3 (20E5186d)
Report Version: 7
Analysis Tool: /usr/bin/leaks
Physical footprint: 400K
Physical footprint (peak): 400K
----
leaks Report Version: 4.0
Process 53270: 169 nodes malloced for 9 KB
Process 53270: 2 leaks for 32 total leaked bytes.
2 (32 bytes) << TOTAL >>
1 (16 bytes) ROOT LEAK: 0x7fb679405b10 [16]
1 (16 bytes) ROOT LEAK: 0x7fb679405b20 [16]
Is there any alternative on MacOS whilst we wait for this fix? Thanks
I'm under the impression Xcode's Instruments is supposed to fill Valgrind's shoes, though I haven't tried it myself yet.
For applicable projects, if you use clang, you can try its LeakSanitizer. I couldn't get this to work with the system's compiler, but it works with Homebrew-installed clang. Clang's sanitizers are really nice since they provide call stack traces for each leak or use-after-free.
Personally, I'm looking for something to replace callgrind/cachegrind. LLVM provides some tools for generating profiling data (llvm-profdata merge and llvm-cov show), but it's only good for seeing how many times each section of code is run.
I'm not sure if it can be used as a stopgap, but this article describes how to extract the system libraries from the cache on Big Sur: https://lapcatsoftware.com/articles/bigsur.html
@tfmorris, a bunch of system seem to exist to extract this information, Apple even ships a function to do that as part of dyld (you just have to build the code at the end of this file yourself: https://opensource.apple.com/source/dyld/dyld-750.6/launch-cache/dsc_extractor.cpp.auto.html). I guess you could technically extract them in /usr and it might just work? (not sure how good a thing that is)
In other news, I have adapted some of Valgrind's internals to accept reading from memory instead of from a file. However, the format of the Mach-O files in the cache seem fairly different to how Valgrind (and most programs) expects them. So I am currently in the process of replicating the whole "extract a library from cache" logic inside Valgrind itself. I did manage to extract the list of symbols through a few hacks so hopefully that's the last hurdle to get proper Big Sur support.
For those who need memory leak detection (aka LeakSanitizer) try this
In Preferences | Build, Execution, Deployment | CMake -> Cmake options use
-DCMAKE_BUILD_TYPE=ASAN -DCMAKE_CXX_COMPILER=/usr/local/opt/llvm/bin/clang++
and
Just a quick update: I am still working on this in the background and made some progress but not to a point where valgrind can properly parse the dyld cache in order to read symbols (which is what is required to get leak tracking, etc). As always, I will post update here when I get past the current hurdles.
Just a quick update: I am still working on this in the background and made some progress but not to a point where valgrind can properly parse the dyld cache in order to read symbols (which is what is required to get leak tracking, etc). As always, I will post update here when I get past the current hurdles.
Checking in to mention the issue persists on Monterrey as well.
in case it helps, my main use case for valgrind-macos is to use callgrind/cachegrind, not the memory checker. that that reduce the blockers for 11/12 support in any meaningful way?
