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 in background during onFlagSyncComplete #267

Closed
pandavid87 opened this issue Apr 8, 2022 · 2 comments
Closed

Crash in background during onFlagSyncComplete #267

pandavid87 opened this issue Apr 8, 2022 · 2 comments
Labels
Stale waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness.

Comments

@pandavid87
Copy link

Describe the bug
Seeing a crash come in via Xcode Organizer related to the FlagSynchronizer. Looks like there is some callback that is dispatched on the main queue, which triggers a lock and resulted in the app being terminated by Watchdog.

To reproduce
No clear reproductions steps.

Expected behavior
App should not crash in the backgrond

Logs

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: FRONTBOARD 2343432205 
<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[application<com.fitbod>:89995] failed to terminate gracefully after 5.0s
ProcessVisibility: Background
ProcessState: Running
WatchdogEvent: process-exit
WatchdogVisibility: Background
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 7.860 (user 5.450, system 2.410), 18% CPU",
"Elapsed application CPU time (seconds): 0.051, 0% CPU"
) reportType:CrashLog maxTerminationResistance:Interactive>

Triggered by Thread:  0


Kernel Triage:
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get


Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001cd8b5178 __ulock_wait + 8
1   libdispatch.dylib             	0x0000000195a5941c _dlock_wait + 56 (lock.c:326)
2   libdispatch.dylib             	0x0000000195a591d0 _dispatch_thread_event_wait_slow + 56 (lock.c:366)
3   libdispatch.dylib             	0x0000000195a67f70 __DISPATCH_WAIT_FOR_QUEUE__ + 356 (lock.h:330)
4   libdispatch.dylib             	0x0000000195a67b28 _dispatch_sync_f_slow + 144 (queue.c:1774)
5   libswiftDispatch.dylib        	0x00000001af8cdcac implicit closure #2 in implicit closure #1 in OS_dispatch_queue.sync<A>(execute:) + 180
6   libswiftDispatch.dylib        	0x00000001af8ccd0c partial apply for implicit closure #2 in implicit closure #1 in OS_dispatch_queue.sync<A>(execute:) + 56 (<compiler-generated>:0)
7   libswiftDispatch.dylib        	0x00000001af8cd9ec OS_dispatch_queue._syncHelper<A>(fn:execute:rescue:) + 396 (Queue.swift:317)
8   libswiftDispatch.dylib        	0x00000001af8ccdbc OS_dispatch_queue.sync<A>(execute:) + 168 (Queue.swift:369)
9   fitbod                        	0x00000001058d4c64 featureFlags.get + 88 (FlagStore.swift:28)
10  fitbod                        	0x00000001058d4c64 featureFlags.get + 96 (<compiler-generated>:28)
11  fitbod                        	0x00000001058d4c64 LDClient.onFlagSyncComplete(result:) + 740 (LDClient.swift:679)
12  fitbod                        	0x0000000105940780 partial apply for closure #1 in FlagSynchronizer.reportSyncComplete(_:) + 32 (FlagSynchronizer.swift:266)
13  fitbod                        	0x00000001059410f0 thunk for @escaping @callee_guaranteed () -> () + 20 (<compiler-generated>:0)
14  libdispatch.dylib             	0x0000000195a56e68 _dispatch_call_block_and_release + 32 (init.c:1517)
15  libdispatch.dylib             	0x0000000195a58a2c _dispatch_client_callout + 20 (object.m:560)
16  libdispatch.dylib             	0x0000000195a66f48 _dispatch_main_queue_drain + 928 (inline_internal.h:2622)
17  libdispatch.dylib             	0x0000000195a66b98 _dispatch_main_queue_callback_4CF + 44 (queue.c:7770)
18  CoreFoundation                	0x0000000195daa2f0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 (CFRunLoop.c:1795)
19  CoreFoundation                	0x0000000195d641f4 __CFRunLoopRun + 2532 (CFRunLoop.c:3144)
20  CoreFoundation                	0x0000000195d776b8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
21  GraphicsServices              	0x00000001b1e11374 GSEventRunModal + 164 (GSEvent.c:2200)
22  UIKitCore                     	0x00000001986dce88 -[UIApplication _run] + 1100 (UIApplication.m:3511)
23  UIKitCore                     	0x000000019845e5ec UIApplicationMain + 364 (UIApplication.m:5064)
24  fitbod                        	0x0000000104de969c main + 68 (FBALargeCardOnboardTableViewCell.swift:32)
25  dyld                          	0x0000000106281ce4 start + 520 (dyldMain.cpp:879)

SDK version
5.4.5

OS/platform
iOS 14+

Additional context
Based on the crash logs I'm seeing, we only started seeing this crash after we updated from LaunchDarkly SDK version 5.4.4 -> 5.4.5

@louis-launchdarkly
Copy link
Contributor

Hello @pandavid87, sorry for the delay. We are looking into this and I have a couple of questions.

Does this happen frequently from your record? And does the device(s) that experienced this error have a good internet connection? Given the 5.4.5 change only updated the swift-eventsource library, we are suspecting there is an edge case for the fix we did that happens when the connection is not good.

keelerm84 added a commit that referenced this issue Dec 29, 2023
There are several bits of information that can contribute to upstream
service cache hits. One of these is the shape of the context payload. By
maintaining a stable encoding format, we can increase the likelihood of
a cache hit.
keelerm84 added a commit that referenced this issue Dec 29, 2023
There are several bits of information that can contribute to upstream
service cache hits. One of these is the shape of the context payload. By
maintaining a stable encoding format, we can increase the likelihood of
a cache hit.
keelerm84 added a commit that referenced this issue Dec 29, 2023
There are several bits of information that can contribute to upstream
service cache hits. One of these is the shape of the context payload. By
maintaining a stable encoding format, we can increase the likelihood of
a cache hit.
This was referenced Dec 29, 2023
keelerm84 pushed a commit that referenced this issue Jan 3, 2024
🤖 I have created a release *beep* *boop*
---


##
[8.4.0](8.3.1...8.4.0)
(2023-12-29)


### Features

* Store and use e-tag header between SDK initializations
([#268](#268))
([701aaa8](701aaa8))


### Bug Fixes

* LDContext equality is no longer order dependent
([#265](#265))
([683e0c3](683e0c3))
* Use stable encoding format to increase cache hits
([#267](#267))
([40a5d01](40a5d01))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: LaunchDarklyReleaseBot <LaunchDarklyReleaseBot@launchdarkly.com>
keelerm84 added a commit that referenced this issue Jan 3, 2024
🤖 I have created a release *beep* *boop*
---


##
[9.3.0](9.2.1...9.3.0)
(2024-01-02)


### Features

* Store and use e-tag header between SDK initializations
([#268](#268))
([701aaa8](701aaa8))


### Bug Fixes

* LDContext equality is no longer order dependent
([#265](#265))
([683e0c3](683e0c3))
* Use stable encoding format to increase cache hits
([#267](#267))
([40a5d01](40a5d01))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: LaunchDarklyReleaseBot <LaunchDarklyReleaseBot@launchdarkly.com>
Co-authored-by: Matthew Keeler <mkeeler@launchdarkly.com>
@keelerm84 keelerm84 added the waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness. label Feb 9, 2024
Copy link
Contributor

This issue is marked as stale because it has been open for 30 days without activity. Remove the stale label or comment, or this will be closed in 7 days.

@github-actions github-actions bot added the Stale label Mar 11, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness.
Projects
None yet
Development

No branches or pull requests

3 participants