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

CRASH: LDClient.go(online:reasonOnlineUnavailable:completion:) #235

Closed
NishanthMurugan opened this issue Jan 21, 2021 · 13 comments
Closed

Comments

@NishanthMurugan
Copy link

NishanthMurugan commented Jan 21, 2021

Hi Team,

we got many crash on this in a single day. please help to resolve.

Crashed: com.apple.main-thread
0 libdispatch.dylib 0x1996ca7d8 dispatch_group_leave.cold.1 + 36
1 libdispatch.dylib 0x199697c00 _dispatch_group_wake + 138
2 LaunchDarkly 0x1068728f4 partial apply for closure #2 in LDClient.go(online:reasonOnlineUnavailable:completion:) + 44 (:44)
3 LaunchDarkly 0x106843a94 partial apply for closure #1 in closure #1 in closure #1 in FlagChangeNotifier.notifyObservers(user:oldFlags:) + 28 (:28)
4 LaunchDarkly 0x10681e2b0 thunk for @escaping @callee_guaranteed () -> () + 28 (:28)
5 libdispatch.dylib 0x19969524c _dispatch_call_block_and_release + 32
6 libdispatch.dylib 0x199696db0 _dispatch_client_callout + 20
7 libdispatch.dylib 0x1996a47ac _dispatch_main_queue_callback_4CF + 836
8 CoreFoundation 0x199a1e11c CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16
9 CoreFoundation 0x199a18120 __CFRunLoopRun + 2508
10 CoreFoundation 0x199a1721c CFRunLoopRunSpecific + 600
11 GraphicsServices 0x1b151b784 GSEventRunModal + 164
12 UIKitCore 0x19c455fe0 -[UIApplication _run] + 1072
13 UIKitCore 0x19c45b854 UIApplicationMain + 168
14 REVEL 0x104047960 main + 29 (AppDelegate.swift:29)
15 libdyld.dylib 0x1996d76b0 start + 4

@torchhound
Copy link
Contributor

Hi @NishanthMurugan thank you for reporting this. This seems like it might be an issue related to your implementation, please reach out to support@launchdarkly.com so you can provide us with additional context for this crash in a confidential manner.

@NishanthMurugan
Copy link
Author

NishanthMurugan commented Jan 21, 2021

Sure @torchhound. If it is implementation issue, this crash should happen all the time right.
But it is happened suddenly between 12 AM - GST to 1 AM - GST in production and became stable now.
Will check with support team if it is due to down time or any other issue. Thank you.

@provTheodoreNewell
Copy link

We just observed a series of similar crash traces starting shortly after we changed the name and description of a feature flag on the LaunchDarkly console (the flag's key stayed the same). Unclear if there's any causation. We're reaching out to support as well.

@provKevinONeill
Copy link

provKevinONeill commented Jan 22, 2021

I work with provTheodoreNewell above, and we continue to investigate this issue and confer with LD support. (we also don't believe it's related to the feature-flag rename Theodore cited above.)

The crashes we observed have also been time-constrained in that they appeared between 230p-4p PST and we haven't seen any since. We have been able to consistently reproduce crashes in the SDK v5.3.1 when we throttle network speeds to 256k/3G, something we haven't been able to reproduce with earlier versions of the SDK.

@ismael9291
Copy link

Any updates on this crash?
I am also seeing multiple crashes pointing to
LDClient.go(online:reasonOnlineUnavailable:completion:)

Although I am unsure if any flags were modified like mentioned above. I am also not seeing a bunch of crashes during a short period of time. Our crashes are more spread out but they started on December 23rd on our production build even though we added Launch Darkly back in September. We are using Launch Darkly version 5.1 through cocoapods.

Please let me know if any additional info is needed to determine if its a potential issue with how I am implementing the cocoapod vs an issue with Launch Darkly itself.

@maciejtrybilo
Copy link

@bwoskow-ld You closed my ticket and said you wanted to consolidate the conversation here. But LD hasn't had any input here for 13 days and no one is assigned to it. A 3rd party SDK crashing our app is a serious issue for us. Especially if it's from a service that's paid for.

@bwoskow-ld
Copy link
Member

We are currently investigating the issue. We'll update everyone on this GitHub issue when we have more information.

Our team doesn't actively use GitHub's assignee feature on issues; we have a private issue tracker which we use for managing all of our tasks across all of our repositories.

@ismael9291
Copy link

@bwoskow-ld Thank you for the update, please let me know if there's any additional info I can provide to help you and your team investigate the issue.

@FelipeAnimoto
Copy link

We are also experiencing this crash. Let me know if any info that I can provide that could help with the fix.

@holzerryan
Copy link

holzerryan commented Feb 3, 2021

I'm also experiencing this issue. Please keep everyone posted with progress or information regarding this crash. I am using the streaming functionality and not polling. Any chance it is related to streaming feature flag updates?

@torchhound
Copy link
Contributor

torchhound commented Feb 4, 2021

Hi all,

We are currently investigating this issue. In some cases it seems like this could be caused by calling identify without waiting for the start completion to return under slow network conditions. This could cause a concurrency bug because the SDK is still receiving flag updates when identify tries to do the same thing. If you are experiencing this crash please check if you are calling the SDK before the start completion has finished, there is also an optional timeout parameter on start if cannot wait during startup. We are looking into other potential causes of this issue as well.

gwhelanLD added a commit that referenced this issue Feb 11, 2021
## [5.3.2] - 2021-02-11
### Fixed
- Updated to prevent a crash in `dispatch_group_leave.cold.1` that would rarely occur as the SDK transitioned to an online state for a given configuration or user. This issue may have been exacerbated for a short period due to a temporary change in the behavior of the LaunchDarkly service streaming endpoint. Thanks to all the users who reported ([#235](#235)).
- Updated `LDSwiftEventSource` dependency to correct an issue where a streaming connection could sometimes reconnect after being set offline.
@gwhelanLD
Copy link
Contributor

We've just released 5.3.2 to address this issue. After investigation, we found multiple probable contributing factors. There was a temporary change to data being served by the streaming endpoint of the LaunchDarkly service that corresponded with the increase of issue reports. The original behavior of the streaming endpoint was restored after our internal integration testing showed a decrease in reliability for our mobile SDKs. Regardless, the SDK should not have experienced crashes from that change. In the release we've added protections to prevent this dispatch_group_leave.cold.1 crash at it's source, and improved the Server-Sent events streaming implementation to avoid potential issues caused by inconsistent stream shutdown behavior.

Feel free to reach out here or to our support team if experience any more issues.

Thanks for the patience,
@gwhelanLD

@lennartstolz
Copy link

We got this issue reported in our crash reporting today. Did you have a similar issue as last time?
(For the users running an old app version that uses the SDK version 5.1).

tanderson-ld pushed a commit that referenced this issue Aug 2, 2023
This pull request was auto generated by the Launchdarkly Github
Standards automation platform.

* Add default CODEOWNERS file
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests