Valgrind mac os big sur

PERPETUAL ENIGMA

PERENNIAL FASCINATION WITH ALL THINGS TECH

How To Install Valgrind On Mac OS X

As your code gets bigger, keeping track of memory becomes critical. These things often become the source of huge crashes and annoying bugs. Detecting them manually is a very tedious process. So we need a tool to manage all this for us. This is where Valgrind comes into picture. Valgrind is a programming tool for memory debugging, memory leak detection, and profiling. It can be used to keep track of all the memory allocated at all stages in your program. Although it was initially meant to be a memory debugger, it has grown to become a generic framework for building dynamic analysis tools. You can use Valgrind to build new tools as well. There are Valgrind tools like Memcheck that can automatically detect many memory management and threading bugs, and profile your programs in detail. Valgrind is widely used in the industry and it’s well respected within the coding community. Let’s see how we can get it up and running on Mac OS X.

Assuming you have svn installed (usually comes pre-installed with OS X), get the latest valgrind repo by executing the following command:

This will create a directory called “valgrind”. Make sure you have Macports installed. If not, install from here. Once you install it, use it to install “automake”:

For OS X Mountain Lion, running the above command might sometimes throw an error saying that the Xcode you have is not the latest version (even though you have the newer version). It will look something like this:

Error: The installed version of Xcode (2.0 or lower) is too old to use on the installed OS version. Version 4.5.2 or later is recommended on Mac OS X 10.8.

This happens because it uses some default path. Use the following command to change it:

Change the name from “Xcode46-DP3” to whatever version you have. Xcode46-DP3 refers to Xcode 4.6 Developer Version 3.

Now run the automake install command again and it will work.

We have to install another dependency called “autoconf” before proceeding further. Execute the following command to do it:

Now we are all set to install valgrind. Run the following commands to install it:

And you are done! We are all set to use valgrind now. Execute the following command to use valgrind on your code.

This will display minimal information on the command line. To see full details, execute the following command:

Here, “a.out” is the default executable generated after compiling the code. If you using a different name, replace it appropriately.

A quick note before ending this post. Valgrind is supposed to be buggy for OS X Mountain Lion. The above installation procedure will work just fine but Valgrind may not detect memory leaks in a few cases. So just be careful about that!

Источник

Getting Valgrind to run on macOS 10.15 Catalina

I’m looking at getting Valgrind to run on macOS 10.15 Catalina.

So far I have the build working OK (based on a fork for 10.14 plus a few tweaks specific to 10.15).

However when I run Valgrind [and I’m running the minimal —tool=none with an app that is just «int main(void) <>«] then I’m getting an error related to pthread_init. From what I see from the executed machine code, there is a test for _os_xbs_chrooted (a global variable in the kernel by the looks of it) which then leads to a call to __pthread_init.cold.2. This function contains a ud2 opcode which triggers a SIGILL in the Valgrind VM.

Dearching google for _os_xbs_chrooted doesn’t come up with anything much. There’s this https://github.com/apple/darwin-libpthread/blob/master/src/pthread.c for the pthread check, and one other reference for the initialization.

I realize this looks like it could be security related and information is not made public.

Any suggestions as to how I can proceed? I have little experience in kernel programming.

Answers

I haven’t looked at this in depth, but

is not new in 10.15; you can see it in the Darwin source for 10.14. Specifically, check out .

btw It’s likely that the

referenced here is not security related, but rather refers to an internal build system used here at Apple.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

Hmm. The official version of Valgrind doesn’t support 10.14 either, and I don’t have a 10.14 system to test with.

What I’m seeing is the following (this is the Valgrind opcode dump, not the execution sequence)

// this is the read of _os_xbs_chrooted

0x1005F5DB2: movq 41575(%rip),%rax

// checking to see if it is zero

0x1005F5DB9: cmpb $0, (%rax)

// if equal jump to ECB

0x1005F5DBC: je-32 0x1005F5ECB

// these opcodes not executed

0x1005F5ECB: call 0x1005FD7A6

0x1005F5DC2: movq -48(%rbp),%rax

0x1005F5DC6: movq 42299(%rip),%rcx

0x1005F5DCD: xorq %r13,%rcx

// target of above jump, call __pthread_init.cold.2

0x1005F5ECB: call 0x1005FD7A6

0x1005FD7A6: leaq 2759(%rip), %rcx

0x1005FD7AD: xorl %eax,%eax

0x1005FD7AF: movq %rcx,11002(%rip)

0x1005FD7B6: movq %rax,11043(%rip)

It seems to me that it is expecting _os_xbs_chrooted to be non-zero. However I have no idea what system call or other is required to change the value of this variable.

However I have no idea what system call or other is required to change the value of this variable.

The code that sets

is not part of Darwin, alas.

The official version of Valgrind doesn’t support 10.14 either, and I don’t have a 10.14 system to test with.

It’s going to be a lot of easier to reason about this stuff if you have Darwin source that correlates to the OS you’re testing on. Can you set up 10.14. <1,2,3>in a VM? Critically, those 10.14.x releases have kernel source available (the xnu project).

It seems to me that it is expecting

That’s unlikely. What’s more likely is that there’s been a failure earlier, and you’re now on a fallback path, and that fallback path is only enabled if

For example, one example I found relates to the way that pthreads sets up its workqueue interaction with the kernel. If the kernel doesn’t understand the modern setup mechanism — this can happen if you run a new user space on top of an old kernel — pthreads will fallback to a legacy mechanism, but it’ll only do this if

As to what’s going on in your specific situation, it’s hard to say without more context. I’m not going to be able to help you on the 10.15 side of things, because there’s no Darwin source for 10.15.x. Let me know if you can reproduce the problem on one of the 10.14.x builds I mentioned above.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

Источник

Big Sur (macOS 11.0) compatibility #19

Comments

ncovercash commented Nov 3, 2020 •

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

The text was updated successfully, but these errors were encountered:

DiegoMagdaleno commented Nov 16, 2020

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

MattiaMontanari commented Nov 20, 2020

LouisBrunner commented Nov 21, 2020

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 commented Nov 23, 2020

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

LouisBrunner commented Nov 23, 2020

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

karimvafin commented Dec 5, 2020

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 commented Dec 5, 2020

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

LouisBrunner commented Dec 11, 2020

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).

Источник

Valgrind mac os big sur

Valgrind for macOS

This repository contains a version of Valgrind including a few patches to improve support for the macOS platform. It is maintained by Louis Brunner.

Valgrind now builds and works on every macOS version

Note that some features are still in progress:

• crash when using wqthread (used in certain UI frameworks)
• using threads and signals is undefined

It is currently tested on 10.14.6 and 10.15.4.

Checkout the patches branch for a list of patches that can be directly applied to the upstream Valgrind.

In case you already have Valgrind installed, you might need to brew remove it first.

In order to use this version, first tap this repository:

Then, install valgrind :

You can now use valgrind as normal.

Any brew upgrade will now correctly rebuild the latest LouisBrunner/valgrind instead of the upstream one (which doesn’t support latest macOS versions).

• Get historical build data from sourceforge for macOS 10.13
• pthread and signals blocking (re-enable tests) [patch in progess]
• wqthread broken (see #4) [patch in progress]
• drd thread related crash on 10.15
• -UNHANDLED messages
• Run regtest in parallel [patch in progess]

Some tests are blocking and were therefore disabled on macOS:

Linux (Ubuntu 18.04)

These errors seem to come from the CI environment itself (as they show with or without my changes).

should be (according to the official builds)

Источник

Valgrind mac os big sur

Valgrind is a powerful open-source memory debugger. This is a port of Valgrind for Mac OS X.
http://valgrind.org/
http://www.apple.com/macosx/

Caveat programmer

This port is UNSUPPORTED and INCOMPLETE and BUGGY. It may not find bugs in your program, or run your program correctly, or run your program at all.

Requirements

• Mac OS X 10.5 Leopard.
• An Intel processor (32- or 64-bit).
• As much RAM as you can afford.

Download and build

Valgrind’s Mac OS X support is now part of Valgrind’s main development trunk. Follow their instructions to download and build the latest code.
http://valgrind.org/downloads/repository.html

Some things that don’t work

• PowerPC code
• Signals
• Many system calls
• Objective-C garbage collection
• —db-attach=yes
• Tools other than memcheck

Errors in system libraries

Some system libraries have false positives or legitimate errors. Valgrind has a «suppression file» mechanism to ignore specified errors. This port does not include any suppressions, so you’ll have to discover them on your own. Please do not file bug reports against system libraries on Valgrind evidence alone.

Messages you may see while running

If you see messages like the following, then your program is using a system call that Valgrind doesn’t support. Your program may run incorrectly after this. Messages like the following can probably be ignored. Messages like the following indicate a mismatch between Valgrind’s memory map and the kernel. Occasional failures are expected in multithreaded programs. If the failure repeats for the same address range, then there may be a problem causing false errors or crashes.

Greg Parker
gparker@apple.com
Sealie Software

Источник