Closed NishanthMurugan closed 3 years ago
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.
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.
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.
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.
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.
@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.
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.
@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.
We are also experiencing this crash. Let me know if any info that I can provide that could help with the fix.
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?
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.
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
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
).
Hi Team,
we got many crash on this in a single day. please help to resolve.