Xcode 12.2 Beta 3 on macOS 11 Beta 11: SIGCONT when debugging projects

I don't know if this is a Xcode bug but all my projects just stop debugging with a SIGCONT message. I can still resume them but this is annoying.

I can even reproduce the issue by creating a new Mac app with the basic project template and it'll SIGCONT as soon as I start debugging.

Replies

I'm getting this all over the place with building and running my apps on Xcode 12.2 Beta 3 on macOS 11 Beta 10. Hope there's a work around or fix. Also continuing doesn't always work for me.
Same here, Xcode can not load my apps.
I have ended up adding a scheme to my project to build and run without(!) debugging as a halfway work around. Most of my apps will continue (Control-Command-Y has never been so helpful), but one of my apps fails to run if its launch is interrupted this way—so no debug for that one.
Thank you. The tip to create a scheme with "Debug executable" turned off in the Run settings is working for me.

No ideal but at least I can run my apps now.
Check "Debug process as root" can fix it.
This has been bugging me all afternoon. I had also just installed macOS 11b10 (20A5395g).

In a post from 9 months ago, Quinn shows that lldb will stop at SIGCONT by default and suggests a temporary workaround:
Code Block
(lldb) process handle -n false -s false SIGCONT

I tried and failed to get this to work in my .lldbinit, then found this old SO post:

At present the suggestion of doing this in a breakpoint command on main is the most elegant solution available.

I added a symbolic breakpoint for main that runs the above debugger command and continues. It fixes the annoying issue of the debugger pausing immediately, although lldb-rpc-server will still use an entire CPU core while doing nothing…

The best I've got, if you want to launch and still debug:
  1. In the Run settings, change Launch from Automatically to Wait for executable to be launched

  2. ⌘+R to Run (which will also build)

  3. Once "Waiting to attach to <Target>" shows, manually launch your built binary from Finder and the debugger will automatically attach

This consistently works for me
Experiencing the same problem. Fixed by choosing "Debug Process as Root" in Schema "Run" -> "Info".
Yup same experience - even with a brand new Xcode SwiftUI template project.

Confirm that the "Debug process as root" fixes it for now...
Just to add some feedback, I've also hit that issue with macOS 11 Beta 10 and Xcode 12.2 beta 2 (I hadn't updated to beta3 yet). So It may not be just an Xcode 12.2 beta 3 thing.
I have a workaround:

Add a symbolic breakpoint

Symbol: _main
Module: dyld
Action: Debugger Command with the command process handle -n false -s false SIGCONT
Options: Check Automatically continue after evaluating actions
Just to add a little information here as well. I can't debug with Xcode 12.1 GM Seed. If I attempt to, it immediately stops at dyld'__fcntl. This is only happening after updated to BigSur beta 10 and happens on both my iMac and MacBook Pro. I also tried a template project and get the same thing. It appears there's something pretty wrong with BigSur beta 10.

However, Xcode 12.2 beta 3 does seem to work for me.

Fortunately, the "Debug process as root" setting resolves debugging with 12.1.
This is also happening to me. It happened to me after I upgraded to macOS 11 Beta 10, but before Xcode 12.2 Beta 3. I was still on Beta 2 when I first saw the crash. So then I upgraded to Xcode 12.2 Beta 3 and it still crashes.

I knew it had to be something with the debugger because I could launch the built application from the Finder, but not from within Xcode.

Thanks for the workarounds. At least I can run now.
At first I was able to simply hit the continue button in the debugger, to run my app. Now it's stopping in a different place, and when I hit continue the app never shows up. The stack frame it stops in is now dyld`ImageLoader::trieWalk.
Same problem. After I installed macOS 11.0 beta (20A5395g) and Xcode 12.2 beta 3 (12B5035g) all my mac projects are crashing with the same error message. The symbolic breakpoint mentioned above by aussiebloke solves the problem.