Wordpress-ios: EXC_BREAKPOINT: release

[sentry-io[bot]]

Sentry Issue: WORDPRESS-IOS-1PJD

EXC_BREAKPOINT: release
  ?, in <redacted>
  ?, in <redacted>
  ?, in <redacted>
  ?, in <redacted>
  ?, in <redacted>
...
(43 additional frame(s) were not displayed)

Over the past 14 days:

~1.7k events
~1.3k affected users

[JavonDavis]

This one looks like a new crash that started from 13.2. Based on a quick look through a lot of these events seems to be originating from SiteStatsInsightsTableViewController @ScoutHarris could you take a look at this one and let me know what you think?

cc @designsimply

[designsimply]

24-day impact: ~1800
Users affected in the last 24 days: 1300
First seen in: 13.2

^{https://sentry.io/share/issue/ec2d659519cc49d2b36a4fb2c47b8b1f/}

[ScoutHarris]

Hey @JavonDavis . I don't think this is related to Stats. Reviewing the events, there are typically multiple other VCs that appear after Stats and before the crash. Also, Stats is often the first view presented on app launch, which can be a bit misleading.

The only consistency I did see is SplitViewController. I didn't look through all 1.7k events, but I didn't see one that occurred on a non-split view device.

[designsimply]

🤔 I'm not sure yet what label to give this crash, but it's worth a quick note to say SplitViewController is most likely limited to landscape orientation.

[sentry-io[bot]]

Sentry issue: WORDPRESS-IOS-1K1W

[designsimply]

36-day impact: ~150 per day
Users affected in the last 90 days: 3700
First seen in: 13.2.0.8

^{https://sentry.io/share/issue/ec2d659519cc49d2b36a4fb2c47b8b1f/}

^ that link stopped working for some reason and the shared link is now: https://sentry.io/share/issue/4bb6106bf01f4a4c93c7e52cccceae36/ — I am not sure if that happened because something was merged or if someone regenerated a shared URL (which is possible to do from the Sentry Details page), it was probably the 2nd thing but unintentional.

45-day impact: ~9 per day
Users affected in the last 45 days: 305
First seen in: 13.2.0.6
Limited to: iOS 13.0 and above

^{https://sentry.io/share/issue/02f00415b29d4356b9619604b851e704/}

[designsimply]

@danielebogo could you help point this one in the right direction? It's the largest new crash we're tracking in GitHub that's new in iOS 13 and started in version 13.2 of the app. The error "EXC_BREAKPOINT: release" is so vague that I don't know where to start with this one!

I saw in Sentry that WordPress.UntouchableViewController is the most common transaction for this crash. Is that significant?

[danielebogo]

@designsimply I agree with what @ScoutHarris said and I think this is another example of grouped crash. I had a look to the events list and there are crashes that affected other part of the app with no trace of Stats but always marked as _UIPageViewController_. Btw I found that the share URLs don't work really well. I'm trying to share an event but the shared link open another one 🤔
What we can do is made some test with iOS 13 and the new devices. We already fixed a crash on _UIPageViewController_ and old devices but I don't know if Sentry marked those events as _closed_.

[danielebogo]

@designsimply I also see that this and this are related with _BlogDetailsViewController_ and _NotificationsViewController_ (probably a crash after selecting a notification) and the event number is 406

[designsimply]

Btw I found that the share URLs don't work really well. I'm trying to share an event but the shared link open another one 🤔

I'll look into this!

[UPDATE: I looked at the Sentry shared links and it seems to me that the shared link always points to the main group and the main group lists the latest crash report first. I don't see a way to link to an individual event with a shared link, it seems to always just show the latest one first after clicking "Details".]

[rachelmcr]

This seems to be a crash related to notifications. In each case, the timestamps on the breadcrumbs show the app being left (on a variety of screens, not one in particular) and inactive for a period of time. The crash happens immediately on returning to the app, and the stack trace shows a push notification being handled and an issue with NotificationsViewController.selectRow.

I selected a couple recent crashes and noticed this in the Tracks events history around the time of the crash:

1. They received the push notification: wpios_push_notification_received
2. There's a recorded event: wpios_notification_service_extension_malformed_payload
3. The user tapped the push notification: wpios_push_notification_alert_tapped
4. The notification details are opened: wpios_notifications_notification_details_opened
5. Steps 3-4 are then repeated several times, with the same notification ID.

[ScoutHarris]

Based on @rachelmcr 's findings, I looked into push notifications. Without knowing how a push notification is malformed exactly, I wasn't able to repro it. Nor did I see anything that _might_ crash. So I 🏳️ed it and added some logging that 🤞 may help. Ref https://github.com/wordpress-mobile/WordPress-iOS/pull/12824.

[designsimply]

This came up in 13.7 Crash Feedback Nov 18, 2019 at 6:49 AM:

Opened a push notification right after updating to 13.7. It crashed on launch, but the second launch seemed fine

• 13.7.0.0
• iPhone XS
• iOS 13.2

[yaelirub]

I was searching Apple's documentation to see if anything changed with push notifications in iOS 13 and indeed there are some changes that I believe require our attention but I cannot know for sure that these are the cause for the crashes (though I think we need to update APNS anyways)

I think we need some updated logic for 2 new attributes in the headers sent to devices.

From Apple documentation:

1. apns-push-type:

(Required for watchOS 6 and later; recommended for macOS, iOS, tvOS, and iPadOS) The value of this header must accurately reflect the contents of your notification’s payload. If there is a mismatch, or if the header is missing on required systems, APNs may return an error, delay the delivery of the notification, or drop it altogether.

1. apns-priority (and I believe the more crucial one):

The priority of the notification. If you omit this header, APNs sets the notification priority to 10.
Specify 10 to send the notification immediately. A value of 10 is appropriate for notifications that trigger an alert, play a sound, or badge the app’s icon. Specifying this priority for a notification that has a payload containing the content-available key causes an error.
Specify 5 to send the notification based on power considerations on the user’s device. Use this priority for notifications that have a payload that includes the content-available key. Notifications with this priority might be grouped and delivered in bursts to the user’s device. They may also be throttled, and in some cases not delivered.

@koke , who got the crash yesterday, shared the payload of the notification:
aps = { alert = "..."; badge = 1; category = "...."; "content-available" = 1; "mutable-content" = 1; sound = "n.caf"; "thread-id" = "...."; };

Since the payload includes the content-available, I think we should specify the priority to 5 according to the documentation.

Thoughts on this and how to proceed @koke , @daniloercoli , @jleandroperez, please your help.

[designsimply]

This came up in beta testing for 13.7:

Same crash as last time. IIRC, I left the app on a notification detail the last time I closed it. Tapping on a push notification about a liked post crashed it. I have been able to open other push notifications when I left the app in a different screen, I think

• App version: 13.7 (13.7.0.1)
• Device: iPhone XS
• iOS version: 13.2.3

[designsimply]

This came up in beta testing for 13.7:

Opened the notification of a comment.

• App version: 13.7 (13.7.0.2)
• Device: iPhone 11 Pro Max
• iOS version: 13.3

[koke]

Same crash as last time. IIRC, I left the app on a notification detail the last time I closed it. Tapping on a push notification about a liked post crashed it. I have been able to open other push notifications when I left the app in a different screen, I think

Me again, the relevant crash trace:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001015598ec
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [686]
Triggered by Thread:  0

Thread 0 name:
Thread 0 Crashed:
0   WordPress                       0x00000001015598ec NotificationsViewController.selectRow(for:animated:scrollPosition:) + 1068 (NotificationsViewController.swift:912)
1   WordPress                       0x000000010155b470 NotificationsViewController.showDetails(for:) + 628 (NotificationsViewController.swift:664)
2   WordPress                       0x0000000101569a34 specialized NotificationsViewController.showDetailsForNotificationWithID(_:) + 428 (NotificationsViewController.swift:640)
3   WordPress                       0x000000010155d37c @objc NotificationsViewController.showDetailsForNotificationWithID(_:) + 80 (<compiler-generated>:0)
4   WordPress                       0x0000000101045ce0 -[WPTabBarController showNotificationsTabForNoteWithID:] + 100 (WPTabBarController.m:850)
5   WordPress                       0x00000001016aa248 specialized PushNotificationsManager.handleInactiveNotification(_:completionHandler:) + 320 (PushNotificationsManager.swift:307)
6   WordPress                       0x00000001016aacf4 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed NSDictionary, @guaranteed @... + 120 (<compiler-generated>:0)
7   WordPress                       0x00000001016a694c PushNotificationsManager.handleNotification(_:completionHandler:) + 1716 (<compiler-generated>:0)
8   WordPress                       0x000000010158cd2c specialized InteractiveNotificationsManager.userNotificationCenter(_:didReceive:withCompletionHan... + 784 (InteractiveNotificationsManager.swift:507)
9   WordPress                       0x00000001015889c8 @objc InteractiveNotificationsManager.userNotificationCenter(_:didReceive:withCompletionHandler:) + 96 (<compiler-generated>:0)
10  UIKitCore                       0x00000001b4c05ea4 -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] + 4996 (UIApplication.m:10302)
11  UIKitCore                       0x00000001b41f4734 -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 500 (UIScene.m:1055)
12  UIKitCore                       0x00000001b41f58ac -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 236 (UIScene.m:1315)
13  UIKitCore                       0x00000001b47892ac -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 480 (UIApplicationSceneClientAgent.m:80)
14  FrontBoardServices              0x00000001b5cd69c8 -[FBSSceneImpl updater:didUpdateSettings:withDiff:transitionContext:completion:] + 560 (FBSSceneImpl.m:551)
15  FrontBoardServices              0x00000001b5cfd0a8 __88-[FBSWorkspaceScenesClient sceneID:updateWithSettingsDiff:transitionContext:completion:]_bloc... + 136 (FBSWorkspaceScenesClient.m:356)
16  FrontBoardServices              0x00000001b5ce0fa4 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 240 (FBSWorkspace.m:357)
17  FrontBoardServices              0x00000001b5cfcfc4 __88-[FBSWorkspaceScenesClient sceneID:updateWithSettingsDiff:transitionContext:completion:]_bloc... + 200 (FBSWorkspaceScenesClient.m:355)
18  libdispatch.dylib               0x00000001b07b1fd8 _dispatch_client_callout + 20 (object.m:495)
19  libdispatch.dylib               0x00000001b07b4d1c _dispatch_block_invoke_direct + 264 (queue.c:466)
20  FrontBoardServices              0x00000001b5d23304 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 48 (FBSSerialQueue.m:173)
21  FrontBoardServices              0x00000001b5d22fb0 -[FBSSerialQueue _queue_performNextIfPossible] + 432 (FBSSerialQueue.m:216)
22  FrontBoardServices              0x00000001b5d2351c -[FBSSerialQueue _performNextFromRunLoopSource] + 32 (FBSSerialQueue.m:247)
23  CoreFoundation                  0x00000001b0a8724c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1922)
24  CoreFoundation                  0x00000001b0a871a0 __CFRunLoopDoSource0 + 84 (CFRunLoop.c:1956)
25  CoreFoundation                  0x00000001b0a8695c __CFRunLoopDoSources0 + 264 (CFRunLoop.c:2000)
26  CoreFoundation                  0x00000001b0a817d8 __CFRunLoopRun + 1068 (CFRunLoop.c:2882)
27  CoreFoundation                  0x00000001b0a81084 CFRunLoopRunSpecific + 480 (CFRunLoop.c:3192)
28  GraphicsServices                0x00000001baccf534 GSEventRunModal + 108 (GSEvent.c:2246)
29  UIKitCore                       0x00000001b4bf1670 UIApplicationMain + 1940 (UIApplication.m:4758)
30  WordPress                       0x0000000101095764 main + 240 (main.swift:7)
31  libdyld.dylib                   0x00000001b0900e18 start + 4

[diegoreymendez]

I've assigned this to myself since I'm groundskeeping this week and @yaelirub is AFK.

[diegoreymendez]

I've fixed this particular instance of the issue in this PR.

The problem in this particular case was that when we tried to scroll to the notification, the view wasn't really loaded (due to the App being inactive). Forcing the view to load fixed the crash.

Two notes regarding these EXC_BREAKPOINT issues, which can be useful for anyone triaging or debugging these:

1. These issues are most likely caused by optionals (or IUOs) being forcibly unwrapped when they're nil. They can also be caused by things like divisions by zero or going out-of-bounds in arrays.
2. Due to what I wrote in point 1, we should treat these issues as uniques, as long as the stack trace differs. This can be particularly useful for triaging because then we know how many real issues we have - it's not just one big one.