Problem when trying to debug with lldb on new arm64 M1

Hi everybody,

I’m the maintainer of GNU Prolog (gprolog). I try to port it to the new arm64/darwin apple architecture since a contributor gave me an ssh access to its machine (I can thus only execute commands via command-line bash).

I can compile gprolog (it uses a classical unix-style procedure ./configure + make using gcc (clang)). The machine is pretty fast !

However, at run-time I obtain a segmentation violation which I’d like to debug using lldb. I initially obtained this error: 

error: process exited with status -1 (developer mode is not enabled on this machine and this is a non-interactive debug session.)

I asked the owner of the machine to enable the developer mode. But now I obtain:

error: process exited with status -1 (this is a non-interactive debug session, cannot get permission to debug processes.)

I saw several posts mentioning entitlements (I’m sorry I’m not an expert of Mac). Here is what I obtain with my executable (I created a simple test case executable called ./t):

codesign -d -vvv --entitlements :- ./t
Executable=/Users/ddiaz/GP/src/BipsPl/t
Identifier=t
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=8410 flags=0x20002(adhoc,linker-signed) hashes=260+0 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=c0ddf4ad6672b7c65b2a90d274bb29783625d502
CandidateCDHashFull sha256=c0ddf4ad6672b7c65b2a90d274bb29783625d5021b6e1d67c6be5c7774c265b5
Hash choices=sha256
CMSDigest=c0ddf4ad6672b7c65b2a90d274bb29783625d5021b6e1d67c6be5c7774c265b5
CMSDigestType=2
CDHash=c0ddf4ad6672b7c65b2a90d274bb29783625d502
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

I saw, in some posts, a permission com.apple.security.get-task-allow which should be enable. Do you think the problem comes from this permission ? How can I add it using command-line console ?

Thanks you for your help

Didou

Replies

You should be able to set up a command-line build environment without GUI access to the machine. Here’s the process I used…

I set up a victim machine that had never seen Apple’s developer tools. This was a VM running macOS 11.1 (this is Intel, but I don’t believe that Apple silicon would change this story).

I used my main machine to download the Command Line Tools for Xcode 12.4 package from the Downloads area on the developer web site

Note Click More (at the top right) to get to the archive.

I copied the resulting disk image to the victim VM.

Code Block
% scp Command_Line_Tools_for_Xcode_12.4.dmg virtual-big.local.:


On the victim VM I mounted the disk image:

Code Block
% hdiutil attach Command_Line_Tools_for_Xcode_12.4.dmg


IMPORTANT I’m using an admin account here. If you don’t have an admin account, see below.

I then installed the package:

Code Block
% sudo installer -pkg /Volumes/Command\ Line\ Developer\ Tools/Command\ Line\ Tools.pkg -target /


I ran DevToolsSecurity to enable developer mode:

Code Block
% sudo DevToolsSecurity -enable
Developer mode is now enabled.


I created a tiny test tool:

Code Block
% cat > hello.c
#include <stdio.h>
int main(int argc, char ** argv) {
printf("Hello Cruel World!\n");
return 0;
}
^D
% clang -g -o hello hello.c


I ran it, just to make sure it compiled OK:

Code Block
% ./hello
Hello Cruel World!


I then ran it under LLDB:

Code Block
% lldb hello
(lldb) target create "hello"
Current executable set to '/Users/quinn/hello' (x86_64).
(lldb) br set -n main
Breakpoint 1: where = hello`main + 22 at hello.c:3:3, address = 0x0000000100003f66
(lldb) r
Process 1951 launched: '/Users/quinn/hello' (x86_64)
Process 1951 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100003f66 hello`main(argc=1, argv=0x00007ffeefbffa40) at hello.c:3:3
1 #include <stdio.h>
2 int main(int argc, char ** argv) {
-> 3 printf("Hello Cruel World!\n");
4 return 0;
5 }
Target 0: (hello) stopped.
(lldb)




The above assumes you’re an admin user. If not, you can ask an admin user to run the commands that require sudo. That resolves most of the issues here, but there’s still one final niggle. At the last step you see this:

Code Block
% lldb hello
(lldb) target create "hello"
Current executable set to '/Users/mrgumby/hello' (x86_64).
(lldb) br set -n main
Breakpoint 1: where = hello`main + 22 at hello.c:3:6, address = 0x0000000100003f66
(lldb) r
error: process exited with status -1 (this is a non-interactive debug session, cannot get permission to debug processes.)
(lldb)


A quick trick to the DevToolsSecurity man page reveals that you have to be either a member of admin or _developer to use LLDB. If the machine admin won’t add you to the admin group you can ask them to add you to _developer. An easy way to do this is with this command:

Code Block
% sudo dseditgroup -o edit -a UUU -t user _developer


replace UUU with your user name.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
  • How would you go about debugging this if the 'hello' test didn't work under lldb? I followed your steps and when I try to run the process under lldb with "r", it instantly dies with error: process exited with status -1 (lost connection). I'm an admin, and I tried adding myself to _developer just in case - but no luck.

    I'm seeing the same error on other processes (an Electron app is where it first appeared), and what's interesting is that debugging with lldb was working until recently and I'm not sure what changed. I tried disabling SIP and that didn't help.

    Also interesting is that Xcode is able to run/attach to these processes just fine (both Electron, and this 'hello' example). It seems like it's probably a security flag somewhere but I'm not sure where to look. I'm on macOS Monterey 12.0.

Add a Comment
Hi,

Adding the _developer group to my account solved the problem.

Thank you very much !