xcode pauses execution with SIGCONT

Question

Created Jan ’20

Replies 2

Boosts 0

Views 2.5k

Participants 2

In a particular project this happens most frequently, however I wasn't unable to find this on the net as something that sometimes happens.

When I run a project on a particular computer (on another fresh installed computer I have no issues), sometimes the execution pauses with SIGCONT.

I am able to resume the code, but then it stops again, and again, and again (on different points, to be honest, so not a loop kind of thing).

In the end I have multiple stops but if I restart execution most of the time it works. This happens only on the startup phase, and could be related to some network troubles, or using a proxy (proxyman) to debug network traffic.

I searched for lldb settings or "stop on all exception" kind of things, to no avail.

Any Idea? this is driving me crazy. I tried also reinstalling xcode, checking out the sources from git again.. any kind of debugging technique that popped to my mind. Since this is my main development machine, I think I could have some settings related to openssl, brew, some packages I installed that is conflicting with lldb.

`mach_msg_trap` is the most common point where it stops.

`dyld_start` another

Any help would be appreciated.

Answered by superandrew in 401025022

It looks like I found the external cause for all the SIGCONT. There is an application called App Tamer that is supposed to slow down applications that are clogging the CPU. Probably I misconfigured it by telling to slow down the simulator when it was running over 100%, and App Tamer as part of its managing processes is sending SIGCONT. There is still a doubt on why XCode stops execution for a SIGCONT, though.

So happy I found the cause of this problem, thank you Eskimo and also Jon of St. Claire Software which was so kind to help.

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’20

LLDB, and hence Xcode, has infrastructure to stop in the debugger when the process receives a signal. I’m a little surprised that this kicks in for

SIGCONT

, but I ran a quick test here [1] and that definitely seems to be the case. Wacky.

There’s two ways you could approach this:

You could try to get LLDB to stop catching the
```
SIGCONT
```
signal (A)
You could track down who is generating these
```
SIGCONT
```
signals and stop them (B)

Personally, I’d focus on B because getting lots of

SIGCONT

signals is just weird.

With regards A, in my tests I found that the following prevents me stopping in the debugging when the process receives

SIGCONT

:

(lldb) process handle -n false -s false SIGCONT

With regards B, these signals can be raised from both inside and outside of your process. For the inside case, you should do the following:

(lldb) thread backtrace all

to see if anything obvious shows up in any of those backtraces.

For the outside case… well, that depends on what platform you’re working on. On the Mac, there are things you can do to investigate this. On iOS and friends, your options are much more limited (but they shouldn’t be sending you

SIGCONT

signals anyway).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Specifically, I created a new Mac app and wired a button up to this code:

- (IBAction)testAction:(id)sender {
    #pragma unused(sender)
    NSLog(@"-[AppDelegate testAction:]");
    raise(SIGCONT);
}

and I end up in the debugger when I click the button.

0

Answer 2

superandrew OP

Jan ’20

Accepted Answer

It looks like I found the external cause for all the SIGCONT. There is an application called App Tamer that is supposed to slow down applications that are clogging the CPU. Probably I misconfigured it by telling to slow down the simulator when it was running over 100%, and App Tamer as part of its managing processes is sending SIGCONT. There is still a doubt on why XCode stops execution for a SIGCONT, though.

So happy I found the cause of this problem, thank you Eskimo and also Jon of St. Claire Software which was so kind to help.

0