Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the option to ignore non fully blocking app hangs #3492

Closed
9 tasks done
Tracked by #4261
philipphofmann opened this issue Dec 13, 2023 · 0 comments · Fixed by #4379
Closed
9 tasks done
Tracked by #4261

Add the option to ignore non fully blocking app hangs #3492

philipphofmann opened this issue Dec 13, 2023 · 0 comments · Fixed by #4379
Assignees

Comments

@philipphofmann
Copy link
Member

philipphofmann commented Dec 13, 2023

Description

Our app hang logic detects app hangs that don't fully block the main thread, which leads to inaccurate stack traces for such app hang events because the app hang logic might fire a bit too late to capture the proper stack trace responsible for the app hang. For some customers non-fully-blocking app hangs are noise, and they often disable the whole feature. Instead, we could provide an option only to report fully blocking app hangs. The option could be an enum something like reportAppHangLevel with (we have to come up with better names)

  1. FullyBlocking
  2. NonBlocking
  3. None

Implementation

To achieve this, we have to change our implementation a bit and might have to combine it with the CADisplayLink, which we already use for the SentryFramesTracker, but we have to be careful cause this can increase the CPU overhead, as pointed out here

* @discussion We decided against using a @c CFRunLoopObserver or the @c CADisplayLink, which the
* @c SentryFramesTracker already uses, because they come with two disadvantages. First, the
* solution is expensive. Quick benchmarks showed that hooking into the main thread's run loop and
* checking for every event to process if the main thread executes it in time added around 0,5 % of
* CPU overhead. Furthermore, if the main thread runs all scheduled events in time, it doesn't mean
* that there is no ANR ongoing. It could be that the run loop of the main thread is busy for 20
* seconds, and it executes all events in time. Instead, what matters is how long the main thread
* needs to execute a newly added event to the run loop.

Related GH discussion: #2715
Related GH issue for linking app hangs to profiles #3493.

@philipphofmann philipphofmann moved this from Needs Discussion to Backlog in Mobile & Cross Platform SDK Dec 20, 2023
@kahest kahest moved this to Needs Discussion in Mobile & Cross Platform SDK Feb 13, 2024
@philipphofmann philipphofmann moved this from Needs Discussion to Todo in Mobile & Cross Platform SDK Feb 14, 2024
@philipphofmann philipphofmann self-assigned this Aug 8, 2024
@philipphofmann philipphofmann moved this from Todo to In Progress in Mobile & Cross Platform SDK Aug 8, 2024
philipphofmann added a commit that referenced this issue Aug 12, 2024
This is the first step for #3492, which is part of the EPIC AppHang improvements #4261.
philipphofmann added a commit that referenced this issue Aug 13, 2024
Add SentryFramesDelayResult containing framesContributingToDelayCount,
which is the count for the frames that contributed to the frames delay
count. This is required for GH-3492.
philipphofmann added a commit that referenced this issue Aug 14, 2024
Add SentryFramesDelayResult containing framesContributingToDelayCount,
which is the count for the frames that contributed to the frames delay
count. This is required for GH-3492.
philipphofmann added a commit that referenced this issue Aug 16, 2024
Add SentryFramesDelayResult containing framesContributingToDelayCount,
which is the count for the frames that contributed to the frames delay
count. This is required for GH-3492.
philipphofmann added a commit that referenced this issue Aug 16, 2024
Add the logic for non-fully-blocking app hangs when the frame delay
exceeds 99%. This is required for GH-3492.
philipphofmann added a commit that referenced this issue Aug 16, 2024
Add the logic for non-fully-blocking app hangs when the frame delay
exceeds 99%. This is required for GH-3492.
philipphofmann added a commit that referenced this issue Aug 16, 2024
Add the logic for non-fully-blocking app hangs when the frame delay
exceeds 99%. This is required for GH-3492.
philipphofmann added a commit that referenced this issue Sep 30, 2024
Expose the AppHangsV2 algorithm with the options
enableAppHangTrackingV2 and
enableReportNonFullyBlockingAppHangs.

Fixes GH-3492
@philipphofmann philipphofmann mentioned this issue Sep 30, 2024
7 tasks
@github-project-automation github-project-automation bot moved this from In Progress to Done in Mobile & Cross Platform SDK Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant