We are having a problem in our C++ app with dlopen returning memory addresses which were previous reserved using mmap() with the MAP_ANON | MAP_PRIVATE | MAP_JIT flags. The mmap is memory is 4Kb page-aligned and returns normally, however sometime later dlopen() is returning an address within the mmap range when no munmap() has been performed. This looks like a bug in the macOS kernal memory manager. Back in July, I opened support ticket FB14442215 where one of our Engineers was able to create a similar and reproducible problem using Preview to load a large bitmap. This ticket has not yet been acted upon, still showing a status of "Open" . Any help or suggestions would be most welcome. Norm Green norm(dot)green(at)gemtalksystems(dot)com

What is the correct way to increase sysv shared memory limits which survives a system reboot? Currently we create this file: /Library/LaunchDaemons/com.gemtalksystems.shared-memory.plist ` File attributes: normg@oink>xattr -l com.gemtalksystems.shared-memory.plist com.apple.provenance: This used to work but no longer does. Now I have to manually execute: sysctl kern.sysv.shmmax=12884901888 after reboot to increase the limits which is not ideal. Is there a better way? System info: normg@oink>sw_vers ProductName: macOS ProductVersion: 13.5 BuildVersion: 22G74 /Library/LaunchDaemons normg@oink>uname -a Darwin oink.gemtalksystems.com 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:17:35 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8112 arm64