Bug 399584 - Support macOS Mojave (10.14)
Summary: Support macOS Mojave (10.14)
Status: CONFIRMED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.14 SVN
Platform: Homebrew (macOS) macOS
: NOR normal
Target Milestone: ---
Assignee: Rhys Kidd
URL:
Keywords:
: 401274 418106 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-09 23:24 UTC by James Hilliard
Modified: 2022-06-07 15:53 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch for compiling on MacOS Mojave. (6.21 KB, patch)
2018-12-14 00:54 UTC, Dejan Jevtic
Details
configure.ac: automatically detect xcode path (2.36 KB, application/mbox)
2019-10-08 15:59 UTC, James Hilliard
Details
configure.ac: automatically detect xcode path (2.39 KB, application/mbox)
2019-10-21 14:49 UTC, James Hilliard
Details
attachment-6878-0.html (8.50 KB, text/html)
2020-01-26 11:11 UTC, i.am.qix
Details
attachment-13484-0.html (1.38 KB, text/html)
2020-02-23 12:55 UTC, i.am.qix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Hilliard 2018-10-09 23:24:27 UTC
Build fails on macOS Mojave with error:
checking for the kernel version... unsupported (18.0.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x, 13.x, 14.x, 15.x, 16.x and 17.x (Mac OS X 10.6/7/8/9/10/11 and macOS 10.12/13)

 https://jenkins.brew.sh/job/Homebrew%20Core%20Pull%20Requests/31627/version=mojave_testing/console
Comment 1 Rhys Kidd 2018-10-12 17:50:44 UTC
Hi James,

Thanks for the report and for creating this bug request.

I'll continue to use this bug report as a meta-bug to track any specific problems with macOS Mojave (10.14) and valgrind.

Hopefully this wont take too long, but at this stage I don't have an estimate of when this support will be in place with valgrind git.

Summary of "the why":
* The report is correct.
* Valgrind ties closely into the kernel interfaces of each operating system is supports, macOS is no different here.
* Each new version of macOS brings with it changes to the mach kernel (sometimes these changes are material, other times less so).
* Apple's mach kernel is not developed in the open (although it is subsequently released as source code some months after the general public Mojave release to the public)
* The source code is not currently available at: https://opensource.apple.com/

While there is some preliminary support work that can begin already, once the source code becomes available, we are in a better position to ship Valgrind support for macOS Mojave (10.14).
Comment 2 Imad Djebarni 2018-11-14 13:49:28 UTC
Hello,

I'm trying to install Valgrind on macOS Mojave since this morning, and i'm getting the same error as James. 

Do you know when it'll be fix please ?

Best Regards.
Comment 3 Rhys Kidd 2018-11-14 15:06:17 UTC
The Mojave kernel source code is still not publicly released at https://opensource.apple.com/.

You should follow up with the vendor of your operating system, Apple, to ask why they have not done so. There is a contact email address: opensource@apple.com

With the public release of the binary kernel over a month ago, not providing the corresponding source code is contrary to their Apple Public Source License.
Comment 4 Tom Hughes 2018-11-21 13:30:38 UTC
*** Bug 401274 has been marked as a duplicate of this bug. ***
Comment 5 Raul Ferreira 2018-12-10 22:40:38 UTC
Just letting everyone know this came out today.

https://opensource.apple.com/source/xnu/xnu-4903.221.2/
Comment 6 Dejan Jevtic 2018-12-14 00:54:17 UTC
Created attachment 116912 [details]
Patch for compiling on MacOS Mojave.

Hi,

I attached initial path (valgrind_mojave_v1.diff) for compiling Valgrind on MacOS Mojave.
Almost all tests will fail because we need to
create suppressions (darwin18.supp).
Comment 7 Rhys Kidd 2018-12-14 00:57:35 UTC
Thanks for this patch as a starting point - I'll take a look, including the suppression file, which I have some experience with generating from the last OS update.

There are a couple of other locations in the code base where the new kernel calls will need to be template'd out.
Comment 8 i.am.qix 2019-01-29 00:44:02 UTC
Rhys, have you gotten a chance to look at the diff? This is blocking a lot of our development on MacOS unfortunately, and build/dist from source isn't a viable option for us at the moment.
Comment 9 Rhys Kidd 2019-01-29 04:10:24 UTC
(In reply to i.am.qix from comment #8)
> Rhys, have you gotten a chance to look at the diff? This is blocking a lot
> of our development on MacOS unfortunately, and build/dist from source isn't
> a viable option for us at the moment.

Hi - I have a slightly more updated work-in-progress commit here [0].

Please note, this remains *very* alpha quality. I am still not happy with the number of failing Valgrind unit tests on Mojave, so you should be very cautious before actioning a report from Valgrind on Mojave in your own code. There is the potential for many false positives and false negatives.

I'll make the plea as well. If your employer or organization is reliant upon Valgrind on macOS, please consider how you could support this critically under-resourced open source project on which you are building. This is more than financial, there are a number of different ways to support important open source communities.

[0] https://github.com/Echelon9/valgrind/commit/742cf660a9b6a933eec60b5791fd342325018395
Comment 10 Imad Djebarni 2019-02-01 10:10:00 UTC
Hi Guys,

Mojave sources are available on https://opensource.apple.com/. 

Best regards.
Comment 11 nolan.d.obrien 2019-03-04 20:01:06 UTC
Mojave sources have been available for over a month.  Just wondering if there's been any update.
Comment 12 Rhys Kidd 2019-03-11 02:30:59 UTC
No major updates to report.
I have a work-in-progress patch series, although there's still a need to properly address some build environment changes on macOS and then confirm that our suppression suite isn't masking any major bugs on macOS Mojave.
Comment 13 Ivan 2019-05-19 01:32:34 UTC
*** This bug has been confirmed by popular vote. ***
Comment 14 Louis Brunner 2019-06-09 11:17:34 UTC
Rhys,

I have been working on a series of patches based on your GitHub repository that allow Valgrind to work on macOS Mojave (albeit fairly experimentally).

The following are included:
 - Empty stub for `mach_msg_destroy` which is required by the new mig
 - A bunch of suppressions for dyld related functions (which are probably way too generic)
 - `openat` support
 - `thread_get_special_reply_port` support
 - Output/check improvements for a handful of syscalls
 - Multi-threading support (signals are still buggy)

I also added a README.md containing the result of `make regtest` for reference.

The code is available here: https://github.com/LouisBrunner/valgrind-macos
Comment 15 Jake Waksbaum 2019-06-25 19:36:29 UTC
Louis, can you make available the patches you applied in order to get it working? I would like to add them to the nixpkgs build script for Valgrind to get it working on High Sierra, until this is fixed.
Comment 16 Louis Brunner 2019-06-25 20:48:58 UTC
Jake,
Just apply the changes from every commit (https://github.com/LouisBrunner/valgrind-macos/commits/master) from the one made by Rhys (15d7631e71300670f6870307631447317d542e1a) to the penultimate (1caa52605dce5241bd9072b61b347b25adaea0a1).
Comment 17 Aaron Liu 2019-06-30 11:42:29 UTC
Hey there Louis. I just checked out your experimental patch, but while trying to install it using homebrew, I got this error in the link below.

https://gist.github.com/aaronliu0130/d2bccb6a39f196bcfa0ecd74f97914ab

How can I fix it?
Comment 18 Aaron Liu 2019-06-30 11:44:13 UTC
Hey there Louis. I just checked out your experimental patch, but while trying to install it using homebrew, I got this error in the link below.

https://gist.github.com/aaronliu0130/d2bccb6a39f196bcfa0ecd74f97914ab

How can I fix it?
Comment 19 Aaron Liu 2019-06-30 13:53:48 UTC
Sorry for the double comment...
Comment 20 James Hilliard 2019-10-08 15:59:39 UTC
Created attachment 123092 [details]
configure.ac: automatically detect xcode path

I created a patch which should fix errors due to /usr/include not existing in most cases.
Comment 21 Rhys Kidd 2019-10-09 02:04:57 UTC
Thanks James -- that's a neat patch and looks to resolve the concerns I've had about alternative, but very brittle, solutions.

I'll give it a test tonight and if all fine, commit it to master.
Comment 22 Rhys Kidd 2019-10-16 10:47:29 UTC
James, running your patch on macOS 10.11 over an otherwise succesfully compiling valgrind master now reports the following build error. Any ideas?:

...
Making all in coregrind
(cd m_mach && mig /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/mach_vm.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/thread_act.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/vm_map.defs)
(cd m_mach && mig /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/mach_vm.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/thread_act.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/vm_map.defs)
(cd m_mach && mig /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/mach_vm.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/thread_act.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/vm_map.defs)
(cd m_mach && mig /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/mach_vm.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/thread_act.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/vm_map.defs)
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: type 'dyld_kernel_image_info_array_t' not defined
mig: fatal: "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: 1 errors found. Abort.

make[2]: *** [m_mach/thread_actUser.c] Error 1
make[2]: *** Waiting for unfinished jobs....
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: type 'dyld_kernel_image_info_array_t' not defined
mig: fatal: "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: 1 errors found. Abort.

"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: type 'dyld_kernel_image_info_array_t' not defined
mig: fatal: "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: 1 errors found. Abort.

make[2]: *** [m_mach/vm_mapUser.c] Error 1
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: type 'dyld_kernel_image_info_array_t' not defined
mig: fatal: "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach/task.defs", line 465: 1 errors found. Abort.

make[2]: *** [m_mach/taskUser.c] Error 1
make[2]: *** [m_mach/mach_vmUser.c] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Comment 23 James Hilliard 2019-10-16 13:38:40 UTC
(In reply to Rhys Kidd from comment #22)

When was the change made in OSX that requires using the SDK path? Maybe we need to only do the SDK path autodetection for newer OSX versions.

Does it work ok for you on newer osx versions such as 10.13? I only have systems set up with 10.14 at the moment so it's a little tricky for me to test myself.
Comment 24 Rhys Kidd 2019-10-20 21:33:40 UTC
I believe Apple made this change in an Xcode release (version 10?), not a version of macOS per se.

However, it appears that for systems that were upgraded from older Xcode or older macOS releases, the previous /usr/include headers were left in place -- but freshly built systems would not have them.

My primary development system is still on macOS 10.11, and was progressively upgraded from around macOS 10.8 or so.

So for me here, these are the following copies of system headers that I can find:

- /usr/include/
- /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
- /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/

I have access to a second system, which was installed at macOS 10.13 and upgraded to macOS 10.14. It only sees:

- /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/

I have only installed the CommandLineTools on that system for now.
Comment 25 James Hilliard 2019-10-21 14:49:51 UTC
Created attachment 123381 [details]
configure.ac: automatically detect xcode path

(In reply to Rhys Kidd from comment #24)
Made a few changes to my patch which should hopefully get it working by always using /usr/include when available.
Comment 26 Rhys Kidd 2019-10-28 22:55:34 UTC
Thanks James -- your revised build script patch has been pushed to valgrind master.

I saw no build regressions on master, 3.15.0 or luisbrunner's out-of-tree branches of valgrind on either my main macOS 10.11 or macOS 10.14 systems.
Comment 27 Heath 2019-11-15 15:21:33 UTC
(In reply to Louis Brunner from comment #14)
> Rhys,
> 
> I have been working on a series of patches based on your GitHub repository
> that allow Valgrind to work on macOS Mojave (albeit fairly experimentally).
> 
> The following are included:
>  - Empty stub for `mach_msg_destroy` which is required by the new mig
>  - A bunch of suppressions for dyld related functions (which are probably
> way too generic)
>  - `openat` support
>  - `thread_get_special_reply_port` support
>  - Output/check improvements for a handful of syscalls
>  - Multi-threading support (signals are still buggy)
> 
> I also added a README.md containing the result of `make regtest` for
> reference.
> 
> The code is available here: https://github.com/LouisBrunner/valgrind-macos

I can confirm that this installed successfully for OSX 10.14, but the leak report didn't look right, I know I had memory leaks but it was showing 0 bytes of loss. I upgraded to OSX 10.15 and now the binary errors with the following:

==7852== Memcheck, a memory error detector
==7852== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7852== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright info
==7852== Command: test
==7852== 
--7852-- UNKNOWN fcntl 101!
--7852-- UNKNOWN fcntl 101! (repeated 2 times)
--7852-- UNKNOWN fcntl 101! (repeated 4 times)
--7852-- UNKNOWN fcntl 101! (repeated 8 times)
--7852-- UNKNOWN fcntl 101! (repeated 16 times)
--7852-- UNKNOWN fcntl 101! (repeated 32 times)
==7852== Use of uninitialised value of size 8
==7852==    at 0x10005A6E3: bcmp (in /usr/lib/dyld)
==7852==    by 0x100022475: ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==7852==    by 0x100028335: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==7852==    by 0x1000214FF: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==7852==    by 0x10000CEEE: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==7852==    by 0x1000149B1: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x100014496: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x1000141F0: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x100013912: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x10000CA7C: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x10000C639: dyld::load(char const*, dyld::LoadContext const&, unsigned int&) (in /usr/lib/dyld)
==7852==    by 0x100015084: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*, unsigned int&) (in /usr/lib/dyld)
==7852== 
==7852== Use of uninitialised value of size 8
==7852==    at 0x10005A6E8: bcmp (in /usr/lib/dyld)
==7852==    by 0x100022475: ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==7852==    by 0x100028335: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==7852==    by 0x1000214FF: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==7852==    by 0x10000CEEE: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==7852==    by 0x1000149B1: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x100014496: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x1000141F0: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x100013912: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x10000CA7C: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==7852==    by 0x10000C639: dyld::load(char const*, dyld::LoadContext const&, unsigned int&) (in /usr/lib/dyld)
==7852==    by 0x100015084: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*, unsigned int&) (in /usr/lib/dyld)
==7852== 
--7852-- UNKNOWN task message [id 8000, to mach_task_self(), reply 0x707]
Comment 28 Ev Drikos 2019-12-03 11:44:28 UTC
> I have been working on a series of patches based on your GitHub repository
> that allow Valgrind to work on macOS Mojave (albeit fairly experimentally).
> 

Hello L. Brunner,

Have seen & used your patch that allows Valgrind to link on 10.14

Regarding "mach_msg_destroy", it's my impression though that the
problem must be somewhere in the compilation/linker flags or in some 
symbol of the pre-processor; because the code below ie builds & runs.

Yet, I don't know the internals of Valgrind very well to inspect it.

Hope this helps,
Ev. Drikos

-------
$ gcc conftest.c && cat conftest.c 
#include <mach/mach.h>
#include <mach/mach_port.h>

int main() {
 mach_msg_header_t msg;
 mach_msg_destroy(&msg);
 return 0;
}
Comment 29 Jay 2020-01-23 19:02:28 UTC
Hi Rhys,

Is there a way to install your patched version of Valgrind using a package manager such as brew? I saw something similar with Louis Brunner (added below), but was wondering if I could do the same with yours since it looks like you and James have made a fair bit of progress towards stability. I'm on 10.14.6 and have been waiting some time to be able to download Valgrind for Mojave through homebrew, but I'm not sure if that's coming anytime soon.

brew install --HEAD https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/valgrind.rb

Also, thank you for your work on keeping Valgrind compatible with macOS. Your work is seriously under-appreciated.

Best,
Jay
Comment 30 Louis Brunner 2020-01-25 13:28:28 UTC
(In reply to Jay from comment #29)
> Hi Rhys,
> 
> Is there a way to install your patched version of Valgrind using a package
> manager such as brew? I saw something similar with Louis Brunner (added
> below), but was wondering if I could do the same with yours since it looks
> like you and James have made a fair bit of progress towards stability. I'm
> on 10.14.6 and have been waiting some time to be able to download Valgrind
> for Mojave through homebrew, but I'm not sure if that's coming anytime soon.
> 
> brew install --HEAD
> https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/
> valgrind.rb
> 
> Also, thank you for your work on keeping Valgrind compatible with macOS.
> Your work is seriously under-appreciated.
> 
> Best,
> Jay

Hi Jay,

I have updated my repository to support macOS 10.14.6, you can try it out with the same command: brew install --HEAD https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/valgrind.rb

Feel free to raise any issue you encounter.
Comment 31 i.am.qix 2020-01-26 11:11:09 UTC
Created attachment 125426 [details]
attachment-6878-0.html

Hi Louis,

Thanks for the continued patches. I'm getting an error on install; I'd open
an issue on your fork but issues appear to be disabled.

MacOS 10.14.6
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

```
==> Cloning https://github.com/LouisBrunner/valgrind-macos.git
Updating /Users/anonymous/Library/Caches/Homebrew/valgrind--git
From https://github.com/LouisBrunner/valgrind-macos
   2dab32498..b69e5363e  master     -> origin/master
==> Checking out branch master
Already on 'master'
Your branch is behind 'origin/master' by 14 commits, and can be
fast-forwarded.
  (use "git pull" to update your local branch)
HEAD is now at b69e5363e Merge pull request #2 from LouisBrunner/feature/ci
==> ./autogen.sh
==> ./configure --prefix=/usr/local/Cellar/valgrind/HEAD-b69e536
--enable-only64bit --build=amd64-darwin
--with-xcode-path=/Applications/Xcode.app/Contents/Developer/Platforms/MacOS
==> make
Last 15 lines from /Users/anonymous/Library/Logs/Homebrew/valgrind/03.make:
clang -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1
-DVGPV_amd64_darwin_vanilla=1     -arch x86_64 -O2 -g -Wall
-Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wenum-conversion -finline-functions -fno-stack-protector
-fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign
-Wno-tautological-compare -mmacosx-version-min=10.6 -O2  -c -o
memcheck_amd64_darwin-mc_machine.o `test -f 'mc_machine.c' || echo
'./'`mc_machine.c
clang -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1
-DVGPV_amd64_darwin_vanilla=1     -arch x86_64 -O2 -g -Wall
-Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wenum-conversion -finline-functions -fno-stack-protector
-fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign
-Wno-tautological-compare -mmacosx-version-min=10.6 -O2  -c -o
memcheck_amd64_darwin-mc_errors.o `test -f 'mc_errors.c' || echo
'./'`mc_errors.c
clang -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1
-DVGPV_amd64_darwin_vanilla=1    -arch x86_64 -O2 -g -Wall
-Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wenum-conversion -finline-functions -fno-stack-protector
-fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign
-Wno-tautological-compare -mmacosx-version-min=10.6 -dynamic -O -g
-fno-omit-frame-pointer -fno-strict-aliasing -fpic -fPIC -fno-builtin  -O2
 -c -o vgpreload_memcheck_amd64_darwin_so-mc_replace_strmem.o `test -f
'mc_replace_strmem.c' || echo './'`mc_replace_strmem.c
clang  -arch x86_64 -O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align
-Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security
-Wignored-qualifiers -Wenum-conversion -finline-functions
-fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align
-Wno-self-assign -Wno-tautological-compare -mmacosx-version-min=10.6
-dynamic -O -g -fno-omit-frame-pointer -fno-strict-aliasing -fpic -fPIC
-fno-builtin  -O2  -dynamic -dynamiclib -all_load -arch x86_64
../coregrind/libreplacemalloc_toolpreload-amd64-darwin.a  -o
vgpreload_memcheck-amd64-darwin.so
vgpreload_memcheck_amd64_darwin_so-mc_replace_strmem.o
../coregrind/link_tool_exe_darwin 0x158000000 clang     -o
memcheck-amd64-darwin   -arch x86_64 -O2 -g -Wall -Wmissing-prototypes
-Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
-Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat
-Wformat-security -Wignored-qualifiers -Wenum-conversion -finline-functions
-fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align
-Wno-self-assign -Wno-tautological-compare -mmacosx-version-min=10.6 -O2
-nodefaultlibs -nostartfiles -Wl,-u,__start -Wl,-e,__start -arch x86_64
memcheck_amd64_darwin-mc_leakcheck.o
memcheck_amd64_darwin-mc_malloc_wrappers.o memcheck_amd64_darwin-mc_main.o
memcheck_amd64_darwin-mc_main_asm.o memcheck_amd64_darwin-mc_translate.o
memcheck_amd64_darwin-mc_machine.o memcheck_amd64_darwin-mc_errors.o
../coregrind/libcoregrind-amd64-darwin.a ../VEX/libvex-amd64-darwin.a -lgcc
link_tool_exe_darwin: /usr/bin/ld -static -new_linker -arch x86_64
-macosx_version_min 10.6 -o memcheck-amd64-darwin -u __start -e __start
-image_base 0x158000000 -stack_addr 0x154000000 -stack_size 0x800000
memcheck_amd64_darwin-mc_leakcheck.o
memcheck_amd64_darwin-mc_malloc_wrappers.o memcheck_amd64_darwin-mc_main.o
memcheck_amd64_darwin-mc_main_asm.o memcheck_amd64_darwin-mc_translate.o
memcheck_amd64_darwin-mc_machine.o memcheck_amd64_darwin-mc_errors.o
../coregrind/libcoregrind-amd64-darwin.a ../VEX/libvex-amd64-darwin.a
link_tool_exe_darwin: ../coregrind/fixup_macho_loadcmds 0x154000000
0x800000 memcheck-amd64-darwin
fixup_macho_loadcmds: requested stack_addr (top) 0x154000000, stack_size
0x800000
fixup_macho_loadcmds: examining tool exe: memcheck-amd64-darwin
fixup_macho_loadcmds:   initial RSP is as expected (0x154000000)
fixup_macho_loadcmds: fail: has __UNIXSTACK, but wrong ::maxprot (should be
7)
make[3]: *** [memcheck-amd64-darwin] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
```

Willing to test any further updates and report back :)

On Sat, Jan 25, 2020 at 2:28 PM Louis Brunner <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=399584
>
> --- Comment #30 from Louis Brunner <louis.brunner.fr@gmail.com> ---
> (In reply to Jay from comment #29)
> > Hi Rhys,
> >
> > Is there a way to install your patched version of Valgrind using a
> package
> > manager such as brew? I saw something similar with Louis Brunner (added
> > below), but was wondering if I could do the same with yours since it
> looks
> > like you and James have made a fair bit of progress towards stability.
> I'm
> > on 10.14.6 and have been waiting some time to be able to download
> Valgrind
> > for Mojave through homebrew, but I'm not sure if that's coming anytime
> soon.
> >
> > brew install --HEAD
> > https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/
> > valgrind.rb
> >
> > Also, thank you for your work on keeping Valgrind compatible with macOS.
> > Your work is seriously under-appreciated.
> >
> > Best,
> > Jay
>
> Hi Jay,
>
> I have updated my repository to support macOS 10.14.6, you can try it out
> with
> the same command: brew install --HEAD
>
> https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/valgrind.rb
>
> Feel free to raise any issue you encounter.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 32 Jay 2020-01-27 03:57:22 UTC
Hey Louis,

First, thanks for the patches and keeping this tool alive and well on MacOS! Also, thanks for the suggestion. I tried to install Valgrind using your repo, but got the same error as 'i.am.qix'. I see they also added their log file, so won't do the same. Would be happy to help try to debug the cause of this issue?

Thanks,
Jay
Comment 33 Louis Brunner 2020-02-23 10:51:52 UTC
Jay, i.am.qix,

I have merged a patch in my repository which should fix that issue.

I didn't realize GitHub issues were disabled, feel free to reopen https://github.com/LouisBrunner/valgrind-macos/issues/3 in case you have any further problems.

Regards,
Comment 34 i.am.qix 2020-02-23 12:55:48 UTC
Created attachment 126335 [details]
attachment-13484-0.html

I can confirm, valgrind is working on MacOS Mojave for me. Thank you
everyone so, so much - it has made my week!

What are the next steps to get this merged into mainline? Can I assist in
some way?

- Josh

On Sun, Feb 23, 2020 at 11:51 AM Louis Brunner <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=399584
>
> --- Comment #33 from Louis Brunner <louis.brunner.fr@gmail.com> ---
> Jay, i.am.qix,
>
> I have merged a patch in my repository which should fix that issue.
>
> I didn't realize GitHub issues were disabled, feel free to reopen
> https://github.com/LouisBrunner/valgrind-macos/issues/3 in case you have
> any
> further problems.
>
> Regards,
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 35 Rhys Kidd 2020-02-23 13:21:58 UTC
Louis has done good work getting a number of the patches and WIP patches together in a downstream fork and which has received some testing from people like yourself.
There is a Valgrind release planned early next month, and I hope to get a number of these patches cleaned up and in mainline for that 3.16 Valgrind release.
Comment 36 Tom Hughes 2020-02-23 20:58:02 UTC
*** Bug 418106 has been marked as a duplicate of this bug. ***
Comment 37 66Ton99 2021-07-28 21:22:43 UTC
(In reply to Rhys Kidd from comment #35)
> Louis has done good work getting a number of the patches and WIP patches
> together in a downstream fork and which has received some testing from
> people like yourself.
> There is a Valgrind release planned early next month, and I hope to get a
> number of these patches cleaned up and in mainline for that 3.16 Valgrind
> release.

It's already 3.17.0 released and new version of MacOS 11.5 (Big Sur) with Darwin 20.6.0 but no moves in this direction. 
Do you have any plans for MacOS?

Thanks.