Fails to attach a debugger process to Glyphs.app on Catalina

Glyphs
1

Some of the plugins I made are written in Objective-C not in Python, and I was able to attach a debugger to Glyphs.app via Xcode so that I could happily set breakpoints to the lines I wrote. After replacing my MacBook with a newer model and migrating to Catalina, it doesn’t work as it used to be – Glyphs.app just won’t launch from Xcode. I observed that the following logs were emitted in Console.app:

default	11:48:21.579314+0900	kernel	macOSTaskPolicy: (com.apple.debugserver) may not get the taskport of (Glyphs) (pid: 22962): (Glyphs) is hardened, (Glyphs) doesn't have get-task-allow, (com.apple.debugserver) is a declared debugger
error	11:48:21.579372+0900	debugserver	error: MachTask::TaskPortForProcessID task_for_pid failed: ::task_for_pid ( target_tport = 0x0103, pid = 22962, &task ) => err = 0x00000005 ((os/kern) failure)
error	11:48:21.593960+0900	debugserver	error: Attach failed: "Not allowed to attach to process.  Look in the console messages (Console.app), near the debugserver entries when the attached failed.  The subsystem that denied the attach permission will likely have logged an informative message ab

Resolving Common Notarization Issues
https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues

As described in the documentation, com.apple.security.get-task-allow needs to be added to the entitlements to have the debugger enabled, but I know that’s not possible because the app gets rejected by the Notary Service. The people in the music industry seems to be facing the same issue, and they circumvent it by re-signing the host application (e.g. Ableton Live) on the plugin developers’ side:

I applied the codesign to Glyphs.app as shown in the post above, but this time Glyphs won’t launch by itself. I’m afraid that Glyphs is terminating itself due to such modification, but I couldn’t figure out what makes it fail to launch exactly. The app icon pops up for a slight moment in the dock, and then it dissapears. No apparent logs can be seen in Console.app.

So, here is my question: is there any established way to enable debugging a native Glyphs plugin? How can I attach a debugger process to Glyphs on Catalina?

2

With notarisation, it doesn’t work anymore. I need to send you a special debug version.

3

Thanks for your reply. I am happy if I can receive the debug version of the latest stable release (2.6.5) for now and I believe that should work.

Switching System Integrity Protection on and off is the thing that I want to avoid the most. The debugger is a killer feature for me in terms of productivity, and sometimes I feel writing a Glyphs plugin in Python is painful because of this.

4

Is a special Glyphs build still needed on Big Sur? I also get an “Could not attach” error when debugging. Running without debug mode works, but having debugging tools available would make developing plugins easier.

5

It is even more needed in Big Sur. The system keeps closing.

6

I would be happy to try such a special build. I’ve rewritten Guten Tag in Swift and it works well, but there are some edge cases that I would like to better debug.

7

This issue is still the pain in the neck for me while I avoid Objective-C (or Swift) wherever possible. Personally I found out a solution to attach a debugger without a special build after I spent a good amount of time for this particular issue, but I say that’s not the way it should be solved. I know most users don’t care about Xcode and just carry on, but the things will get more accessible if such special versions were publicly available.

1 Like
8

I rather not publish those versions for protection reasons. I may publish it on a closed group or a repo. For now, I can send you a new build if I make one.

If you would write a plugin in any other language (I know of), there is not even a change to be able to use a debugger. So this is a HUGE advantage of objC/Swift even if you need to jump some hoops.

1 Like
9

This is my main reason for trying something other than Python.