Problem Statement
A user ran into performance issues when setting appHangTimeoutInterval to zero, which is allowed by the SDK but offers no value:
appHangTimeoutInterval = 0 becomes a busy loop in SentryANRTrackerV2. The V2 tracker's run loop is:
NSTimeInterval sleepInterval = self.timeoutInterval / 5;
while (YES) {
...
[self.threadWrapper sleepForTimeInterval:sleepInterval];
...
}
With timeoutInterval == 0, sleepForTimeInterval:0 returns immediately and the thread pegs a core.
After identifying that the Watchdog termination also enables enableAppHangTracking, the affected user previously set appHangTimeoutInterval = 0 in the app (intending it as a "disable" signal, since SentryHangTrackingIntegration does early-return when the timeout is zero).
However, the Watchdog integration doesn't have the same guard, so it hands 0 straight to the tracker, resulting in a tight loop instead of a no-op.
Solution Brainstorm
Forcing appHangTimeoutInterval to be a value larger than 0 can prevent this configuration issue.
Are you willing to submit a PR?
No response
Problem Statement
A user ran into performance issues when setting
appHangTimeoutIntervalto zero, which is allowed by the SDK but offers no value:appHangTimeoutInterval = 0becomes a busy loop inSentryANRTrackerV2. The V2 tracker's run loop is:With
timeoutInterval == 0,sleepForTimeInterval:0returns immediately and the thread pegs a core.After identifying that the Watchdog termination also enables
enableAppHangTracking, the affected user previously setappHangTimeoutInterval = 0in the app (intending it as a "disable" signal, sinceSentryHangTrackingIntegrationdoes early-return when the timeout is zero).However, the Watchdog integration doesn't have the same guard, so it hands
0straight to the tracker, resulting in a tight loop instead of a no-op.Solution Brainstorm
Forcing
appHangTimeoutIntervalto be a value larger than 0 can prevent this configuration issue.Are you willing to submit a PR?
No response