EXC_BAD_ACCESS KERN_INVALID_ADDRESS on LDClient.start

[TasikBeyond]

trafficstars

Describe the bug Firebase crashlytics is capturing a bad access exception on a small percentage of our sessions.

To reproduce Haven't reproduced locally.

Expected behavior No crash.

Logs

Crashed: TimeOutQueue
0  libobjc.A.dylib                0x2244 objc_retain_x8 + 16
1  libswiftCore.dylib             0x404620 objcRetainAndReturn(void*) + 32
2  Ourapplication                 0x19d74 outlined copy of UserInfo? + 4336622964 (<compiler-generated>:4336622964)
3  Ourapplication                 0x2f89bc outlined retain of UserInfo? + 4339632572 (<compiler-generated>:4339632572)
4  Ourapplication                 0x2f6f0c closure #1 in LaunchDarklyFeatureFlagService.start(_:) + 4339625740
5  Ourapplication                 0x11d1e50 closure #2 in static LDClient.start(serviceFactory:config:context:startWaitSeconds:completion:) + 2589276
6  Ourapplication                 0x11cc62c thunk for @escaping @callee_guaranteed @Sendable () -> () + 2566712 (<compiler-generated>:2566712)
7  libdispatch.dylib              0x3dd4 _dispatch_client_callout + 20
8  libdispatch.dylib              0x72d8 _dispatch_continuation_pop + 600
9  libdispatch.dylib              0x1b1c8 _dispatch_source_latch_and_call + 420
10 libdispatch.dylib              0x19d8c _dispatch_source_invoke + 832
11 libdispatch.dylib              0xb284 _dispatch_lane_serial_drain + 368
12 libdispatch.dylib              0xbf30 _dispatch_lane_invoke + 380
13 libdispatch.dylib              0x16cb4 _dispatch_root_queue_drain_deferred_wlh + 288
14 libdispatch.dylib              0x16528 _dispatch_workloop_worker_thread + 404
15 libsystem_pthread.dylib        0x1f20 _pthread_wqthread + 288
16 libsystem_pthread.dylib        0x1fc0 start_wqthread + 8

Library version LaunchDarkly 9.6.2

XCode and Swift version Xcode 15.3 and Swift 5

Platform the issue occurs on 93% iPhone and 7% iPad

66% iOS 17 27% iOS 16 7% iPadOS 17

33% In Background

[tanderson-ld]

Hello @TasikBeyond , thank you for reporting this and thank you for the percentage breakdown of the platforms. Does that roughly match your userbase? What percentage of sessions is this happening in? Do you have the number of occurences?

[TasikBeyond]

Hey @tanderson-ld

It's a very low percentage of sessions. ~0.01% The platform spread does roughly align with the general user base. There are 19 events over the last seven days. Each from a unique user.

[tanderson-ld]

Thank you for that data, helps to eliminate some possibilities. We're actively looking at this today and I will let know you what we find.

[tanderson-ld]

Did you use a version prior to this version without issue? If so, what version was that? Thank you.

[tanderson-ld]

@TasikBeyond , is the UserInfo a class in your codebase? Do you reference an instance of it in the LDClient.start(...) completion callback? Theory right now is that the start completion in your code base is a spot to investigate.

[TasikBeyond]

Hey @tanderson-ld thank you for looking into this.

There was no prior version, we've recently added the SDK to our project.

UserInfo is a class in our codebase. We build and return an LDContext from a few properties in our UserInfo object.

Our start method looks something like this.

  private func start(_ userInfo: UserInfo?, completion: (() -> Void)? = nil) {
      let config = LDConfig(mobileKey: AppConfiguration.LaunchDarkly.mobileKey, autoEnvAttributes: .enabled)
      let context = buildContext(userInfo: userInfo)
      LDClient.start(config: config, context: context, startWaitSeconds: 10) { [weak self] _ in
          guard let self else { return }
          if let userInfo {
              self.sharedThreadsIsOn = isOn(flag: .sharedThreads, userInfo: userInfo)
          }

          LDClient.get()?.observe(key: LaunchDarklyFeatureFlag.sharedThreads.rawValue,
                                  owner: self,
                                  handler: { [weak self] flag in
              self?.sharedThreadsIsOn = flag.newValue == true
          })
          completion?()
      }
  }

Which is called during didFinishLaunchingWithOptions from our AppDelegate. We will also continue to investigate this area as a potential cause. Thank you.

[Reedyuk]

Hi @TasikBeyond we are also getting this crash. Around 800 users getting the crash, which is a low percentage of our user base but is our current biggest crash right now.

Crashed: com.apple.root.default-qos
0  libswiftCore.dylib             0x4065b4 swift_isUniquelyReferenced_nonNull_native + 38
1  UNiDAYS                        0xbddf3c specialized static ObjcLDClient.start(configuration:context:completion:) + 596 (LDClient.swift:596)
2  UNiDAYS                        0xbdd240 @objc static ObjcLDClient.start(configuration:context:completion:) + 4382528064 (<compiler-generated>:4382528064)

[tanderson-ld]

@Reedyuk, thank you for providing some more info for this issue. Is this actually the same crash or the same exception type?

[Reedyuk]

yes it looks different, i will raise seperately.

[tanderson-ld]

@TasikBeyond , have you found anything out during investigation? At the moment we don't have any further actions we intend to take for this issue.

[TasikBeyond]

Negative. Feel free to close and I'll reach out if I find something more concrete. Thank you!

[tanderson-ld]

Thank you for letting us know and keep us posted.

[TasikBeyond]

Sorry for the late update here. But we did refactor our implementation and these crashes have disappeared entirely. So I think it's fair to say the issue was on our end.

I wish I could point to a specific change but the refactor was fairly large and it's not obvious to me exactly where the issue was in our original implementation.