crash in append when awakening from background

[RangerRick]

Describe the bug My app is configured to disconnect from the event source when backgrounded. When it comes back up, I think there can sometimes be a residual callback pending that tries to get processed but everything has been shut down.

To reproduce Dang good question, I haven't been able to isolate it, but it happens occasionally when I re-foreground my app.

Expected behavior no crash

Logs This is what I get from the crash log. I have no idea how to make it symbolify it properly. If you have any hints on that, I would appreciate it.

Thread 5 name:  Dispatch queue: com.apple.NSURLSession-delegate
Thread 5 Crashed:
0   libsystem_kernel.dylib          0x00000001bb37495c __pthread_kill + 8
1   libsystem_pthread.dylib         0x00000001d62c79e8 pthread_kill + 212
2   libsystem_c.dylib               0x00000001996bf934 abort + 100
3   libsystem_malloc.dylib          0x000000019f389030 _malloc_put + 0
4   libsystem_malloc.dylib          0x000000019f3892a4 malloc_zone_error + 100
5   libsystem_malloc.dylib          0x000000019f377558 free_small_botch + 36
6   libswiftCore.dylib              0x0000000194725714 _swift_release_dealloc + 28
7   libswiftCore.dylib              0x00000001945d1d4c _StringGuts.prepareForAppendInPlace+ 1748300 (totalCount:otherUTF8Count:) + 388
8   libswiftCore.dylib              0x00000001945d1ec0 _StringGuts.append+ 1748672 (_:) + 220
9   libswiftCore.dylib              0x0000000194571730 _StringGuts.append+ 1353520 (_:) + 88
10  LDSwiftEventSource              0x0000000104a1a6fc 0x104a0c000 + 59132
11  LDSwiftEventSource              0x0000000104a18998 0x104a0c000 + 51608
12  LDSwiftEventSource              0x0000000104a166a4 0x104a0c000 + 42660
13  CFNetwork                       0x000000019120d838 0x191047000 + 1861688
14  libdispatch.dylib               0x00000001906ad298 _dispatch_call_block_and_release + 24
15  libdispatch.dylib               0x00000001906ae280 _dispatch_client_callout + 16
16  libdispatch.dylib               0x000000019068a4fc _dispatch_lane_serial_drain$VARIANT$armv81 + 568
17  libdispatch.dylib               0x000000019068b01c _dispatch_lane_invoke$VARIANT$armv81 + 456
18  libdispatch.dylib               0x0000000190694808 _dispatch_workloop_worker_thread + 692
19  libsystem_pthread.dylib         0x00000001d62c85a4 _pthread_wqthread + 272
20  libsystem_pthread.dylib         0x00000001d62cb874 start_wqthread + 8

Library version 1.1.0, but I compared against the 1.2.0 and it appears this part of the code hasn't changed.

XCode and Swift version XCode 12.1, Swift 5.1

Platform the issue occurs on iPhone

Additional context I realize this isn't a lot to go on, but I'm not sure how to debug it further, I'm reasonably new to swift. The code is being called through a Capacitor plugin I wrote so there's some wiggle room in timing between the javascript layer making things happen and that finally getting down to the swift/native layer.

[gwhelanLD]

Hi @RangerRick,

Thanks for opening this issue. Could you elaborate on what calls you are making to LDSwiftEventSource? Particularly if you're doing anything on foregrounding/backgrounding.

Without calling stop explicitly, I'm not sure what you mean by a pending residual callback after the library has been shut down. I would expect it to be a violation of memory rules for the system to free up the library state but allow the URLSession to still call delegate methods, but that goes a bit outside my understanding of how iOS handles backgrounding and application lifecycles.

From the trace, my initial intuition is that maybe UTF8LineParser or EventParser are being used concurrently. But that's not supposed to happen with their use being in URLSession delegates which are called on a serial queue.

For symbolifying the traces - I believe normally it should not be necessary in debug builds, but for release builds the info is normally stripped. I believe the default release configuration should produce a .dSYM file for a particular build to allow re-symbolifying location data, but I don't have a lot of experience with that.

Also of potential use is the logging output, a command like:

xcrun simctl spawn <DEVICE> log stream --level=debug --predicate 'subsystem BEGINSWITH[c] "com.launchdarkly"'

Should provide the logging output of library.

Thanks, @gwhelanLD

[gwhelanLD]

Since we have been able to replicate this issue and have not received additional details about the failure, I'm going to close this issue. If you can replicate with https://github.com/launchdarkly/swift-eventsource/releases/tag/1.3.0, feel free to reopen.

Thanks, @gwhelanLD