Missed a zero from the end of the link https://bugs.kde.org/show_bug.cgi?id=437790

It's about a year since I wrote this, time for a bit of an update, especially in the light of macOS 11. Short version: If you want Valgrind on macOS, then your best bet is to go here Louis Brunner's github repo - https://github.com/LouisBrunner/valgrind-macos/ Louis seems to be working on improving support on macOS 11 Intel. If you are using macOS on ARM, then you are out of luck. Valgrind is supported on ARM/Linux, but not on ARM for any other platform. It should be possible to make Valgrind work on ARM, but this would be a fairly substantial effort. For my part, I'm not actively working on macOS, and have been working more on FreeBSD. I am now the port maintainer on FreeBSD and also contribute to upstream Valgrind. (FreeBSD is not officially supported, I hope that some time in 2021 I'll get the FreeBSD code added upstream).

This seems to be related to ptr_munge... Not sure what we can do in this case.

It looks like I'll have to step through the code on both OSes to try to see the difference. Will get back on this shortly.

I have managed to produce a build on 10.14, but the problem is not reproduced there.So my next step was to run on both Mojave and Catalina with --trace-syscalls=yes. It looks like the one that is failing on Catalina is a thread_selfid syscall.From what I see this ends with the following assembler .text .align 4 .globl _thread_self_trap_thread_self_trap: movq $__NR_thread_self_trap, %rax movq %rcx, %r10 syscall retI guess that this interface might have changed?

Thanks for the info. I'll take a look into setting up a 10.14 VM.I've also been asking on the Valgrind dev mailing list, and your description of the possible cause sounds plausible.

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// __pthread_init.cold.2 0x1005FD7A6: leaq 2759(%rip), %rcx 0x1005FD7AD: xorl %eax,%eax 0x1005FD7AF: movq %rcx,11002(%rip) 0x1005FD7B6: movq %rax,11043(%rip)// game over 0x1005FD7BD: ud2It 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.