EXC_BAD_ACCESS ModalViewManager.swift:63

[fossage]

SDK version: 3.6.0

Environment: Production

Are logs available? No, but we do have crash logs from our error logging software.

Describe the bug

• We have received \~100 crash reports since adding the customerio-reactnative SDK at the beginning of May.
• The issue seems to be happening when a user closes a CustomerIO in-app message.
• The issue is specific to iOS and seems to be happening across a wide range of OS versions and devices.
• We have not bee able to reproduce the issue locally and it seems to happen fairly infrequently to our users(We've sent \~30k IAMs and seen \~100 crashes)

To Reproduce Not able to reproduce locally unfortunately.

Expected behavior The app does not crash

Additional context

• React Native Version: 0.73.6
• Crash Site: Pods/CustomerIOMessagingInApp/Sources/MessagingInApp/Gist/Managers/ModalViewManager.swift:63:16
• Sample Crash Report:

Hardware Model:     iPhone11,8
Role:               Foreground
OS Version:         iOS 17.5.1
Exception Type:     EXC_BAD_ACCESS 
Exception Subtype:  KERN_INVALID_ADDRESS

EXC_BAD_ACCESS: Attempted to dereference garbage pointer 0x20.

0  libobjc.A.dylib +0x9f88         _weak_register_no_lock
1  libobjc.A.dylib +0x9cdc         _objc_storeWeak
2  UIKitCore +0x90ec4              <redacted>
3  UIKitCore +0x8f120              <redacted>
4  Volt +0xf6888                   ModalViewManager.dismissModalView(completionHandler:) (ModalViewManager.swift:63:16)
5  Volt +0xeab50                   specialized GistInAppProvider.dismissMessage() (MessageManager.swift:65:30)
6  Volt +0xf4748                   protocol witness for MessagingInAppInstance.dismissMessage() in conformance MessagingInAppImplementation (MessagingInAppImplementation.swift:51:23)
7  Volt +0xf410c                   MessagingInApp.dismissMessage() (MessagingInApp.swift:109:25)
8  Volt +0x5d3df4                  @objc CustomerioInAppMessaging.dismissMessage() (CustomerioInAppMessaging.swift:32:31)
9  CoreFoundation +0x20810         ___invoking___
10 CoreFoundation +0x1f85c         -[NSInvocation invoke]
11 CoreFoundation +0x961d8         -[NSInvocation invokeWithTarget:]
12 Volt +0x3c7d18                  -[RCTModuleMethod invokeWithBridge:module:arguments:] (RCTModuleMethod.mm:584:3)
13 Volt +0x3c9e20                  facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext) (RCTNativeModule.mm:196:17)
14 Volt +0x3c9a70                  facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)::$_0::operator()() const (RCTNativeModule.mm:113:7)
15 libdispatch.dylib +0x2138       __dispatch_call_block_and_release
16 libdispatch.dylib +0x3dd0       __dispatch_client_callout
17 libdispatch.dylib +0xb3fc       __dispatch_lane_serial_drain
18 libdispatch.dylib +0xbf2c       __dispatch_lane_invoke
19 libdispatch.dylib +0x16cb0      __dispatch_root_queue_drain_deferred_wlh
20 libdispatch.dylib +0x16524      __dispatch_workloop_worker_thread
21 libsystem_pthread.dylib +0x4930 __pthread_wqthread

[mrehan27]

Hi @fossage. Thanks for reaching out and sharing the details. Sorry for the inconvenience caused by this issue. The logs are really helpful and will help us in investigating the possible issue. We'll take a closer look at the code and get back to you with more details. Meanwhile, can you please answer the following:

• Do you notice any pattern in those crashes among users? e.g. Does it mostly occur when the user navigates to a different screen, leaves the app, or interacts with specific in-app message?
• Do you see any pattern among those users, such as a specific Device/OS version, or any other details that might help us reproduce this and investigate the root cause?
• Are you calling dismissMessage anywhere in your app? If yes, can you please share where you are calling it, e.g., on message action, when navigating away from a specific screen, when leaving the app, etc.?

Thanks again for sharing the details. These questions might help us narrow down the issue and find the root cause which will help in fixing and verifying the changes. Appreciate your patience and help in identifying the issue.

[fossage]

@mrehan27 thanks for the follow up.

• We do not notice any specific pattern regarding when it happens. It occurs in different areas of the application, sometimes the users has backgrounded the app in the 30 seconds or so previous, sometimes not. Sometimes they have had network changes slightly previous to the crash, sometimes not. Unfortunately nothing sticks out as an obvious pattern.
• We have seen the crash across 8 different iOS versions and 24 different iPhone models. The distribution of the crashes roughly lines up with what you would expect the distribution of those OS's and devices are amongst users(i.e. most crashes happen on iPhone 13, 14 or 15 on the latest version of iOS)
• We have listeners for both the InAppMessageEventType.messageActionTaken and InAppMessageEventType.messageDismissed events that will explicitly call the CustomerIO.inAppMessaging().dismissMessage() method. In talking with the person who implemented this logic, they couldn't quite recall why we needed it in the InAppMessageEventType.messageDismissed case, but I would guess that it was because we had seen times where the message didn't dismiss appropriately so this was a fallback or something. I'm not sure if that was the actual reason so I wouldn't spend any time investigating it, but we put it there for some explicit reason, haha. For the InAppMessageEventType.messageActionTaken event, we had it there to explicitly dismiss the message after the user interacted with it in any way.

[fossage]

In writing out the above, the explicit call to CustomerIO.inAppMessaging().dismissMessage() after receiving the InAppMessageEventType.messageDismissed event definitely seems like it could be the culprit. We can experiment with removing that, but curious if you have any more insights.

[mrehan27]

Thank you for the great details. We have noted this down and will take a look to see if we can improve anything to minimize the crash occurrence.

However, with the current implementation, if you can remove dismissMessage call from messageDismissed that might help you reduce this crash. The messageDismissed is called only when the message is already being dismissed with animation, and because there is another attempt to dismiss the same message again, this is potentially causing the crash.

I can't think of any use case where you would need to call dismissMessage in messageDismissed, but if you or anyone from your team has any case in mind that makes you keep the method there, do let us know so we can note it down for future improvements.

[fossage]

@mrehan27 , we have released an update where we are no longer explicitly calling CustomerIO.inAppMessaging().dismissMessage() after receiving the InAppMessageEventType.messageDismissed event but unfortunately we are still getting the error in the latest release, albeit with about half the frequency. It is worth noting that we still have a listener set up for the InAppMessageEventType.messageActionTaken event which explicitly calls CustomerIO.inAppMessaging().dismissMessage(). I'm starting to wonder if any calls to CustomerIO.inAppMessaging().dismissMessage() have the potential to cause this error.

[mrehan27]

@fossage Thanks a lot for the updates. Sorry to hear that the issue is still occurring, though it's good to know the occurrences have been reduced. I'll discuss this with team internally to prioritize any possible fix and keep sharing updates here on any progress we make.

Thanks again for your patience and feedback.