I am following the Running Linux in a Virtual Machine guide on MacOS 14 w/ ARM. Fedora kernel and RAM disk images were acquired for aarch64. I opened LinuxVirtualMachine.xcodeproj from the example; selecting 'LinuxVirtualMachine' under 'Targets', and navigating to 'Signing and Capabilities', I linked my Personal Team (needed to connect my Apple ID) under 'Signing->Team'. Clicking 'run' outputs the following: Usage: /Users/shea/Library/Developer/Xcode/DerivedData/LinuxVirtualMachine-baalsbzvoxxbspgicozzllxbyqmh/Build/Products/Debug/LinuxVirtualMachine <kernel-path> <initial-ramdisk-path> Program ended with exit code: 64 So I execute the following in Terminal from a directory containing the two images from Fedora: % /Users/shea/Library/Developer/Xcode/DerivedData/LinuxVirtualMachine-baalsbzvoxxbspgicozzllxbyqmh/Build/Products/Debug/LinuxVirtualMachine ./vmlinuz ./initrd.img And receive the output: Failed to start the virtual machine. Error Domain=VZErrorDomain Code=1 "The virtual machine failed to start." UserInfo={NSLocalizedFailure=Internal Virtualization error., NSLocalizedFailureReason=The virtual machine failed to start.} An old thread seems to imply this may be because the kernel image used to be compressed but is no longer? Another commenter suggests it is because vmlinuzis a gz file and to extract it, but file vmlinuzoutputs vmlinuz: PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows and gzip won't work even with the .gz extension. Did I miss a step?

Consider the following program, memory-leak.c: #include <stdlib.h> void *p; int main() { p = malloc(7); p = 0; // The memory is leaked here. return 0; } If I compile this with clang memory-leak.c and test the output with the built-in MacOS memory leak detector leaks using leaks -quiet -atExit -- ./a.out, I get (partly) the following output: 1 leak for 16 total leaked bytes. However, if I remove the 'leaking' line like so: #include <stdlib.h> void *p; int main() { p = malloc(7); return 0; } Compiling this file and again running leaks now (partly) returns: 0 leaks for 0 total leaked bytes. The man page for leaks shows that it is only un-reachable memory that is considered a leak. Is there a configuration to detect un-free'd reachablemalloc segments?