Post

Replies

Boosts

Views

Activity

macOS mmap / dlopen problem
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
1
0
394
Sep ’24
Increasing shared memory limits with kern.sysv.*
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
1
0
993
Aug ’23
forking lldb to get a complete backtrace
I'm trying to use a technique we use on Linux to get a stack trace of a process that gets in trouble. We fork a debugger in batch mode in a child process to get the back trace of the parent. When I run this, lldb hangs in the attach to the parent process. And since lldb cannot attach to lldb, there's no way for me to see what's blocking lldb in the attach to the parent. Attached is a simple program that demonstrates the problem. Manually running lldb from a shell with the same arguments gets the stack trace. Is there some way around this hang? #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <sys/wait.h> #include <errno.h> #include <poll.h> static void runChild(pid_t parent) { &#9;const char *lldb = "/usr/bin/lldb"; &#9;const char * args[8]; &#9;char pidstr[16]; &#9;snprintf(pidstr, sizeof(pidstr), "%d", (int) parent); &#9;args[0] = lldb; &#9;args[1] = "--no-lldbinit"; &#9;args[2] = "--batch"; &#9;args[3] = "-p"; &#9;args[4] = pidstr; &#9;args[5] = "--one-line"; &#9;args[6] = "thread backtrace all"; &#9;args[7] = NULL; &#9;errno = 0; &#9;char * const * _args = (char * const *) args; &#9;int rc = execv(lldb, _args); &#9;int saveErrno = errno; &#9;if (rc) { &#9;&#9;printf("execv failure, errno = %d\n", saveErrno); &#9;} &#9;_exit(1); } int main(int argc, const char *argv[]) { &#9;pid_t parent= getpid(); &#9; &#9;pid_t child = fork(); &#9;if (child == -1) { &#9;&#9;printf("fork() failure\n"); &#9;&#9;exit(1); &#9;} &#9; &#9;if (child == 0) { &#9;&#9;// we are the child process &#9;&#9;runChild(parent); &#9;} &#9; &#9;// so we are the parent &#9;printf("Waiting for child %d to exit\n", (int) child); &#9;fflush(stdout); &#9;for (;;) { &#9;&#9;errno = 0; &#9;&#9;int status = 0; &#9;&#9;pid_t result = waitpid(child, &status, WNOHANG | WUNTRACED); &#9;&#9;int saveErrno = errno; &#9;&#9;printf("waitpid: rc=%d, exited %d, signaled %d, stopped %d\n", &#9; (int) result, WIFEXITED(status), WIFSIGNALED(status), WIFSIGNALED(status)); &#9;&#9;if (result == -1) &#9;&#9;&#9;break; &#9;&#9;poll(NULL, 0, 1000); // sleep for 1 s and retry &#9;} &#9;exit(0); &#9;return 0; }
3
0
1k
Aug ’20
The dreaded "developer cannot be verified" error. Why?
Hi, (long post, sorry). TLDR: I signed and notarized my a.out executables, shared libs, and dmg file, but still get "developer cannot be verified" error. Why? Gory details: I am trying to get our MacOS app signed and notarized so it can be opened without the dreaded "app cannot be opened because the developer cannot be verified" error. The build and testing are all done in my iMac, which is running Catalina (10.15.6). Our app is a smalltalk database app written in C++ without any GUI components (no bundles). All executables are command line tools in a.out format. All executables and shared libraries are signed. The build is done exclusively via command line tools (not using Xcode, although Xcode is installed). Here are the build steps: Compile and link using g++ (clang) and make. This creates an installation directory tree /Users/normg/gs353/fast42/gs/root Enable hardened runtime and sign all a.out executables and shared libraries with: codesign --options runtime -s "72G58AHU7P"&#9;--entitlements /info.plist Other resource files (text files, shell scripts, binary database data files, etc are not signed). 3. Create a disk image: hdiutil create /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg -srcfolder /Users/normg/gs353/fast42/gs/root 4. Sign the disk image codesign -s "72G58AHU7P" /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg 5. Have the disk image notarized xcrun altool --notarize-app \-primary-bundle-id "com.gemtalk.GemTalkServer" \ &#9;&#9;&#9;&#9;&#9;&#9; --username "norm.green@gemtalksystems.com" \ &#9;&#9;&#9;&#9;&#9;&#9; --password "@keychain:Developer-altool" \ &#9;&#9;&#9;&#9;&#9;&#9; --asc-provider "72G58AHU7P" \ &#9;&#9;&#9;&#9;&#9;&#9; --file "/Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg" 6. Notarization succeeds: normg@idget>xcrun altool --notarization-info "7c78f26d-13c7-4a35-a29b-74ee66862282" --username "norm.green@gemtalksystems.com" --password "@keychain:Developer-altool" No errors getting notarization info. &#9;&#9;&#9;&#9;&#9;Date: 2020-07-16 16:50:44 +0000 &#9;&#9;&#9;&#9;&#9;Hash: 3a237b8ddf3fb412345e3c45971db135de2d23690b94995df73b84d47f367dc8 ... &#9;&#9;&#9;&#9;Status: success &#9; Status Code: 0 Status Message: Package Approved 7. staple the disk image normg@idget>stapler staple /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg Processing: /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg Processing: /Users/normg/tmp/GemStone64Bit3.5.3-i386.Darwin.dmg The staple and validate action worked! Now I download the final signed, notarized and stapled, disk image with a browser (Chrome) and extract it to a directory. That all works. But I still get "app cannot be opened because the developer cannot be verified" error when I attempt run any a.out. The signature is valid: normg@idget>codesign -vvv ./vsdwishDarwin ./vsdwishDarwin: valid on disk ./vsdwishDarwin: satisfies its Designated Requirement and the check-security routine on the a.out passes: normg@idget>./check-signature /Users/normg/GemStone64Bit3.5.3-i386.Darwin/bin/vsdwishDarwin (c) 2014 Apple Inc.&#9;All rights reserved. YES My downloaded dmg is quarantined: normg@idget>xattr -l "GemStone64Bit3.5.3-i386.Darwin (1).dmg" com.apple.diskimages.fsck: ... com.apple.quarantine: 0181;5f10870d;Chrome;AAD23815-6326-4CC8-9178-42494E58AD50 but so is the signaturecheck.dmg I downloaded from apple, and that opens without errors: normg@idget>xattr -l signaturecheck.dmg \com.apple.diskimages.fsck: ... com.apple.quarantine: 0081;5f0fe0f8;Chrome;11737297-FF43-481E-B7BE-B5063943F3EA What do I have to do to avoid the "developer cannot be verified" error? Norm Green
5
0
1.9k
Jul ’20