13 Replies
      Latest reply on Sep 25, 2019 11:45 PM by eskimo
      craiggers Level 1 Level 1 (0 points)

        I'm getting some 0x8b4df00d errors, and I'd like to prevent them...

         

        The basic pattern I'm using is to begin a background task, start background session upload tasks, and then end my background task. With some logging, I've verified that I'm calling endBackgroundTask for each beginBackgroundTask, and my crash reports don't show any http activity on the main thread.

         

        Anywhere else I should look for the cause of 0x8b4df00d problems? I saw in another thread to do a sysdiagnose for more info, but my crashes often happen in the middle of the night as a result of a push notification, so I don't think that's practical in this case. I log to a SQLite database and then send up later, so that's one way I can get more info about what's going on; is there some logging I can do to help find this issue?

        • Re: Okay to call endBackgroundTask after starting a background session upload?
          eskimo Apple Staff Apple Staff (12,305 points)

          Just to clarify, watchdog crashes have the exception code 0x8badf00d (see TN2151).  Is the “0x8b4df00d” value you used throughout your post a typo?  Or a new exception code?

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

            • Re: Okay to call endBackgroundTask after starting a background session upload?
              craiggers Level 1 Level 1 (0 points)

              You're right - it's actually 0x8badf00d, not 0x8b4df00d, my b4d.

               

              Here's a recent trace:

              {"app_name":"rMove","timestamp":"2019-09-12 02:00:56.92 -0400","app_version":"5.3.5890","slice_uuid":"47f8b9fa-0a56-37d2-a929-0750329fa1e6","adam_id":0,"build_version":"5.3.5890","bundleID":"com.rsginc.rmove","share_with_app_devs":true,"is_first_party":false,"bug_type":"109","os_version":"iPhone OS 12.4.1 (16G102)","incident_id":"74EEC9D3-016E-44A6-955F-853FA9DC37D3","name":"rMove"}
              Incident Identifier: 74EEC9D3-016E-44A6-955F-853FA9DC37D3
              CrashReporter Key:   8da83f2024255f42b27b65fe4f430f5c6306c40f
              Hardware Model:      iPhone10,1
              Process:             rMove [2651]
              Path:                /private/var/containers/Bundle/Application/A8A2A142-A0F8-4AF1-A26D-912F6DB12C96/rMove.app/rMove
              Identifier:          com.rsginc.rmove
              Version:             5.3.5890 (5.3.5890)
              Code Type:           ARM-64 (Native)
              Role:                Non UI
              Parent Process:      launchd [1]
              Coalition:           com.rsginc.rmove [1005]
              
              
              
              
              Date/Time:           2019-09-12 02:00:56.7367 -0400
              Launch Time:         2019-09-12 01:00:16.5818 -0400
              OS Version:          iPhone OS 12.4.1 (16G102)
              Baseband Version:    3.70.01
              Report Version:      104
              
              
              Exception Type:  EXC_CRASH (SIGKILL)
              Exception Codes: 0x0000000000000000, 0x0000000000000000
              Exception Note:  EXC_CORPSE_NOTIFY
              Termination Reason: Namespace ASSERTIOND, Code 0x8badf00d
              Triggered by Thread:  0
              
              
              Thread 0 name:  Dispatch queue: com.apple.main-thread
              Thread 0 Crashed:
              0   libsystem_kernel.dylib        0x0000000189a280f4 mach_msg_trap + 8
              1   libsystem_kernel.dylib        0x0000000189a275a0 mach_msg + 72
              2   CoreFoundation                0x0000000189e28120 __CFRunLoopServiceMachPort + 236
              3   CoreFoundation                0x0000000189e23030 __CFRunLoopRun + 1360
              4   CoreFoundation                0x0000000189e227c0 CFRunLoopRunSpecific + 436
              5   GraphicsServices              0x000000018c02379c GSEventRunModal + 104
              6   UIKitCore                      0x00000001b68f3c38 UIApplicationMain + 212
              7   rMove                          0x0000000104d8915c 0x104d84000 + 20828
              8   libdyld.dylib                  0x00000001898e68e0 start + 4
              
              
              Thread 1 name:  com.apple.uikit.eventfetch-thread
              Thread 1:
              0   libsystem_kernel.dylib        0x0000000189a280f4 mach_msg_trap + 8
              1   libsystem_kernel.dylib        0x0000000189a275a0 mach_msg + 72
              2   CoreFoundation                0x0000000189e28120 __CFRunLoopServiceMachPort + 236
              3   CoreFoundation                0x0000000189e23030 __CFRunLoopRun + 1360
              4   CoreFoundation                0x0000000189e227c0 CFRunLoopRunSpecific + 436
              5   Foundation                    0x000000018a7f098c -[NSRunLoop+ 31116 (NSRunLoop) runMode:beforeDate:] + 300
              6   Foundation                    0x000000018a7f081c -[NSRunLoop+ 30748 (NSRunLoop) runUntilDate:] + 96
              7   UIKitCore                      0x00000001b69d9754 -[UIEventFetcher threadMain] + 136
              8   Foundation                    0x000000018a91d4a0 __NSThread__start__ + 984
              9   libsystem_pthread.dylib        0x0000000189ab52c0 _pthread_body + 128
              10  libsystem_pthread.dylib        0x0000000189ab5220 _pthread_start + 44
              11  libsystem_pthread.dylib        0x0000000189ab8cdc thread_start + 4
              
              
              Thread 2:
              0   libsystem_pthread.dylib        0x0000000189ab8cd0 start_wqthread + 0
              
              
              Thread 3 name:  JavaScriptCore bmalloc scavenger
              Thread 3:
              0   libsystem_kernel.dylib        0x0000000189a32ee4 __psynch_cvwait + 8
              1   libsystem_pthread.dylib        0x0000000189ab24a4 _pthread_cond_wait$VARIANT$armv81 + 628
              2   libc++.1.dylib                0x0000000189009090 std::__1::condition_variable::wait+ 32912 (std::__1::unique_lock<std::__1::mutex>&) + 24
              3   JavaScriptCore                0x00000001910b6de0 void std::__1::condition_variable_any::wait<std::__1::unique_lock<bmalloc::Mutex> >+ 564704 (std::__1::unique_lock<bmalloc::Mutex>&) + 108
              4   JavaScriptCore                0x00000001910badd4 bmalloc::Scavenger::threadRunLoop+ 581076 () + 176
              5   JavaScriptCore                0x00000001910ba54c bmalloc::Scavenger::Scavenger+ 578892 (std::__1::lock_guard<bmalloc::Mutex>&) + 0
              6   JavaScriptCore                0x00000001910bbf8c std::__1::__thread_specific_ptr<std::__1::__thread_struct>::set_pointer+ 585612 (std::__1::__thread_struct*) + 0
              7   libsystem_pthread.dylib        0x0000000189ab52c0 _pthread_body + 128
              8   libsystem_pthread.dylib        0x0000000189ab5220 _pthread_start + 44
              9   libsystem_pthread.dylib        0x0000000189ab8cdc thread_start + 4
              
              
              Thread 4 name:  WebThread
              Thread 4:
              0   libsystem_kernel.dylib        0x0000000189a280f4 mach_msg_trap + 8
              1   libsystem_kernel.dylib        0x0000000189a275a0 mach_msg + 72
              2   CoreFoundation                0x0000000189e28120 __CFRunLoopServiceMachPort + 236
              3   CoreFoundation                0x0000000189e23030 __CFRunLoopRun + 1360
              4   CoreFoundation                0x0000000189e227c0 CFRunLoopRunSpecific + 436
              5   WebCore                        0x0000000192b15fc4 RunWebThread+ 3874756 (void*) + 600
              6   libsystem_pthread.dylib        0x0000000189ab52c0 _pthread_body + 128
              7   libsystem_pthread.dylib        0x0000000189ab5220 _pthread_start + 44
              8   libsystem_pthread.dylib        0x0000000189ab8cdc thread_start + 4
              
              
              Thread 5 name:  com.apple.CFStream.LegacyThread
              Thread 5:
              0   libsystem_kernel.dylib        0x0000000189a280f4 mach_msg_trap + 8
              1   libsystem_kernel.dylib        0x0000000189a275a0 mach_msg + 72
              2   CoreFoundation                0x0000000189e28120 __CFRunLoopServiceMachPort + 236
              3   CoreFoundation                0x0000000189e23030 __CFRunLoopRun + 1360
              4   CoreFoundation                0x0000000189e227c0 CFRunLoopRunSpecific + 436
              5   CoreFoundation                0x0000000189e3b500 _legacyStreamRunLoop_workThread + 260
              6   libsystem_pthread.dylib        0x0000000189ab52c0 _pthread_body + 128
              7   libsystem_pthread.dylib        0x0000000189ab5220 _pthread_start + 44
              8   libsystem_pthread.dylib        0x0000000189ab8cdc thread_start + 4
              
              
              Thread 6 name:  com.apple.NSURLConnectionLoader
              Thread 6:
              0   libsystem_kernel.dylib        0x0000000189a280f4 mach_msg_trap + 8
              1   libsystem_kernel.dylib        0x0000000189a275a0 mach_msg + 72
              2   CoreFoundation                0x0000000189e28120 __CFRunLoopServiceMachPort + 236
              3   CoreFoundation                0x0000000189e23030 __CFRunLoopRun + 1360
              4   CoreFoundation                0x0000000189e227c0 CFRunLoopRunSpecific + 436
              5   CFNetwork                      0x000000018a43c74c -[__CoreSchedulingSetRunnable runForever] + 216
              6   Foundation                    0x000000018a91d4a0 __NSThread__start__ + 984
              7   libsystem_pthread.dylib        0x0000000189ab52c0 _pthread_body + 128
              8   libsystem_pthread.dylib        0x0000000189ab5220 _pthread_start + 44
              9   libsystem_pthread.dylib        0x0000000189ab8cdc thread_start + 4
              
              
              Thread 7 name:  IndexedDatabase Server
              Thread 7:
              0   libsystem_kernel.dylib        0x0000000189a32ee4 __psynch_cvwait + 8
              1   libsystem_pthread.dylib        0x0000000189ab24a4 _pthread_cond_wait$VARIANT$armv81 + 628
              2   JavaScriptCore                0x000000019107d88c ***::ThreadCondition::timedWait+ 329868 (***::Mutex&, ***::WallTime) + 80
              3   JavaScriptCore                0x0000000191064514 ***::ParkingLot::parkConditionallyImpl(void const*, ***::ScopedLambda<bool ()> const&, ***::ScopedLambda<void + 226580 ()> const&, ***::TimeWithDynamicClockType const&) + 2004
              4   JavaScriptCore                0x0000000191038358 bool ***::Condition::waitUntil<***::Lock>+ 45912 (***::Lock&, ***::TimeWithDynamicClockType const&) + 184
              5   JavaScriptCore                0x000000019103fb30 ***::CrossThreadQueue<***::CrossThreadTask>::waitForMessage+ 76592 () + 116
              6   JavaScriptCore                0x000000019103fa88 ***::CrossThreadTaskHandler::taskRunLoop+ 76424 () + 216
              7   JavaScriptCore                0x000000019107bb30 ***::Thread::entryPoint+ 322352 (***::Thread::NewThreadContext*) + 260
              8   JavaScriptCore                0x000000019107d03c ***::wtfThreadEntryPoint+ 327740 (void*) + 12
              9   libsystem_pthread.dylib        0x0000000189ab52c0 _pthread_body + 128
              10  libsystem_pthread.dylib        0x0000000189ab5220 _pthread_start + 44
              11  libsystem_pthread.dylib        0x0000000189ab8cdc thread_start + 4
              
              
              Thread 8 name:  WebCore: LocalStorage
              Thread 8:
              0   libsystem_kernel.dylib        0x0000000189a32ee4 __psynch_cvwait + 8
              1   libsystem_pthread.dylib        0x0000000189ab24a4 _pthread_cond_wait$VARIANT$armv81 + 628
              2   JavaScriptCore                0x000000019107d88c ***::ThreadCondition::timedWait+ 329868 (***::Mutex&, ***::WallTime) + 80
              3   JavaScriptCore                0x0000000191064514 ***::ParkingLot::parkConditionallyImpl(void const*, ***::ScopedLambda<bool ()> const&, ***::ScopedLambda<void + 226580 ()> const&, ***::TimeWithDynamicClockType const&) + 2004
              4   WebKitLegacy                  0x0000000194165bdc bool ***::Condition::waitUntil<***::Lock>+ 666588 (***::Lock&, ***::TimeWithDynamicClockType const&) + 184
              5   WebKitLegacy                  0x00000001941688d8 std::__1::unique_ptr<***::Function<void ()>, std::__1::default_delete<***::Function<void ()> > > ***::MessageQueue<***::Function<void ()> >::waitForMessageFilteredWithTimeout<***::MessageQueue<***::Function<void ()> >::waitForMessage()::'lambda'(***::Function<void ()> const&)>(***::MessageQueueWaitResult&, ***::MessageQueue<***::Function<void ()> >::waitForMessage()::'lambda'(***::Function<void + 678104 ()> const&)&&, ***::WallTime) + 156
              6   WebKitLegacy                  0x0000000194167ef4 WebCore::StorageThread::threadEntryPoint+ 675572 () + 68
              7   JavaScriptCore                0x000000019107bb30 ***::Thread::entryPoint+ 322352 (***::Thread::NewThreadContext*) + 260
              8   JavaScriptCore                0x000000019107d03c ***::wtfThreadEntryPoint+ 327740 (void*) + 12
              9   libsystem_pthread.dylib        0x0000000189ab52c0 _pthread_body + 128
              10  libsystem_pthread.dylib        0x0000000189ab5220 _pthread_start + 44
              11  libsystem_pthread.dylib        0x0000000189ab8cdc thread_start + 4
              
              
              Thread 9:
              0   libsystem_pthread.dylib        0x0000000189ab8cd0 start_wqthread + 0
              
              
              Thread 0 crashed with ARM Thread State (64-bit):
                  x0: 0x0000000010004005   x1: 0x0000000007000806   x2: 0x0000000000000000   x3: 0x0000000000000c00
                  x4: 0x0000000000001e03   x5: 0x00000000ffffffff   x6: 0x0000000000000000   x7: 0x0000000000000000
                  x8: 0x00000000fffffbbf   x9: 0x0000000007000000  x10: 0x0000000007000000  x11: 0x000000b2f52e890c
                 x12: 0x00000000016e3600  x13: 0x0000000000338732  x14: 0x0000000000003100  x15: 0x0000310000000000
                 x16: 0xffffffffffffffe1  x17: 0x0000000000000001  x18: 0x0000000000000000  x19: 0x0000000000000000
                 x20: 0x00000000ffffffff  x21: 0x0000000000001e03  x22: 0x0000000000000c00  x23: 0x000000016b07ad10
                 x24: 0x0000000007000806  x25: 0x0000000000000000  x26: 0x0000000007000806  x27: 0x0000000000000c00
                 x28: 0x0000000000000001   fp: 0x000000016b07ac00   lr: 0x0000000189a275a0
                  sp: 0x000000016b07abb0   pc: 0x0000000189a280f4 cpsr: 0x60000000
              
                • Re: Okay to call endBackgroundTask after starting a background session upload?
                  eskimo Apple Staff Apple Staff (12,305 points)

                  my b4d.

                  (-:

                  Crashes like this, with 0x8badf00d but the main thread parked in the run loop, typically indicate that someone is leaking a background execution assertion.  The canonical way to get this is to begin a background task and never end it.  However, there are others.  For example, back in the day there was a bug in UserNotifications framework that caused it to leak background execution asserts, meaning that everyone who used that framework would suffer from crashes like this.

                  As to what’s happening in your specific case, my experience is that the majority of these problems are caused by folks failing to to track their UIApplication background tasks properly.  It’s remarkably get things wrong with that API.  My UIApplication Background Task Notes post has a bunch of info about how best to use it.  Also, the above-mentioned thread has further hints.

                  Another thing to watch out for is UIApplication completion handlers.  When you get a callback like -application:handleEventsForBackgroundURLSession:completionHandler:, it’s vital that you keep track of the completion handler because that completion handlers embed the system equivalent of a UIApplication background task.  If you drop one, you can hit this problem.

                  Share and Enjoy

                  Quinn “The Eskimo!”
                  Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                  let myEmail = "eskimo" + "1" + "@apple.com"

                    • Re: Okay to call endBackgroundTask after starting a background session upload?
                      craiggers Level 1 Level 1 (0 points)

                      Thank you  - I think you nailed it, I think it's the background session completion handler that's getting dropped; it looks like my handleEventsForBackgroundURLSession function is not getting called, so I'm not getting the completion handler.

                       

                      We're using Cordova, so I'm swizzling in this function because we don't have access to the app delegate class. I'm doing this for push notification callbacks, and those are working fine, but I don't see why this function is not getting called.

                       

                      In Cordova's pluginInitialize, I'm calling:

                        static let bgSendingIsSetup:Bool = {
                          NSLog("CordovaInterface bgSendingIsSetup")
                          let app: UIApplication = UIApplication.shared
                          let appDelegate = app.delegate as! CDVAppDelegate
                          let clazz = CDVAppDelegate.self
                          appDelegate.swizzle(clazz, #selector(appDelegate.application(_:handleEventsForBackgroundURLSession:completionHandler:)), 
                                  #selector(appDelegate.swizzled_application(_:handleEventsForBackgroundURLSession:completionHandler:)))
                           return true
                        }()
                      
                      

                       

                      That swizzle function is:

                      extension CDVAppDelegate {
                        func swizzle(_ clazz:AnyClass, _ originalSelector:Selector, _ swizzledSelector:Selector) -> () {
                          let original = class_getInstanceMethod(clazz, originalSelector)
                          let swizzled = class_getInstanceMethod(clazz, swizzledSelector)!
                      
                          if let origMethod = original {
                            method_exchangeImplementations(origMethod, swizzled)
                            Log.log("swizz swapped \(originalSelector) w/ \(swizzledSelector)", true)
                          } else {
                            class_addMethod(clazz, originalSelector, method_getImplementation(swizzled), method_getTypeEncoding(swizzled))
                            Log.log("swizz added \(originalSelector)", true)
                          }
                        }
                      
                      

                       

                      And this is the signature for my replacement function, which looks right to me:

                        @objc dynamic func swizzled_application(_ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void) {
                          Log.log("hEFBUS \(identifier)", true)
                          ...
                      
                      

                       

                      ... but the hEFBUS line never actually gets logged.

                       

                      I'm swizzling the push notification functions (didRegisterForRemoteNotificationsWithDeviceToken, didFailToRegisterForRemoteNotificationsWithError, and didReceiveRemoteNotification:fetchCompletionHandler) at the same point and using the same swizzle function, and those are working... what am I missing?

                        • Re: Okay to call endBackgroundTask after starting a background session upload?
                          eskimo Apple Staff Apple Staff (12,305 points)

                          Swizzling isn’t the right answer here.  There’s two possibilities:

                          • Either your app delegate already has an -application:handleEventsForBackgroundURLSession:completionHandler: method, in which case you want to integrate with that method, not replace it.

                          • Alternatively, if it doesn’t already have that method, you want to add it dynamically, not swizzle it.

                          Personally, I avoid swizzling methods, or even adding methods dynamically, except in extreme circumstances.  In this case I recommend that you modify the existing app delegate code to provide a way to route this method through to libraries within your process.  Cordova is open source, right?

                          Share and Enjoy

                          Quinn “The Eskimo!”
                          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                          let myEmail = "eskimo" + "1" + "@apple.com"

                        • Re: Okay to call endBackgroundTask after starting a background session upload?
                          craiggers Level 1 Level 1 (0 points)

                          I believe I fixed it - the answer was in this StackOverflow post; changing my session identifier got iOS to start calling handleEventsForBackgroundURLSession.

                           

                          Edit: unmarked as the correct answer; not fixed, started happening again with the new session ids.

                            • Re: Okay to call endBackgroundTask after starting a background session upload?
                              eskimo Apple Staff Apple Staff (12,305 points)

                              Well, that’s rather unsatisfactory.  Was the breakage associated with your old session identifier confined to one device?  Also, if you create your session and call -invalidateAndCancel on it, does that fix the problem?

                              Also, you might be interested in my Testing Background Session Code pinned post.

                              Share and Enjoy

                              Quinn “The Eskimo!”
                              Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                              let myEmail = "eskimo" + "1" + "@apple.com"

                                • Re: Okay to call endBackgroundTask after starting a background session upload?
                                  craiggers Level 1 Level 1 (0 points)

                                  > Was the breakage associated with your old session identifier confined to one device?

                                  A couple devices that I was using for development, but not a third. This was development code, so it had limited installations.

                                   

                                  > Also, if you create your session and call -invalidateAndCancel on it, does that fix the problem?

                                  I tried calling invalidateAndCancel from urlSessionDidFinishEvents if the background completion handler isn't set, but it didn't help - urlSessionDidFinishEvents was called on the next pass without a call to handleEventsForBackgroundURLSession.

                                  • Re: Okay to call endBackgroundTask after starting a background session upload?
                                    craiggers Level 1 Level 1 (0 points)

                                    I was able to grab a log... does this help identify the issue?

                                     

                                    Sep 20 14:00:20 Craigs-iPhone assertiond[60] : [rMove:1257] Activate assertion: 
                                    Sep 20 14:00:20 Craigs-iPhone powerd[33] : Process assertiond.60 Created SystemIsActive "rMove:1257:87-AF5F00CC-AF9B-432A-8A6E-0731256F86BA [com.apple.nsurlsessiond.handlesession com.rsginc.rmove.sending.Heart] [0x125d4b0a0]" age:00:00:00  id:51539648732 [System: PrevIdle SysAct]
                                    Sep 20 14:00:20 Craigs-iPhone rMove[1257] : [CDVTimer][heartbeat] 0.234008ms
                                    Sep 20 14:00:20 Craigs-iPhone rMove(libswiftFoundation.dylib)[1257] : LLLLLLLLLLLLLLAAAAAAAAAAAAAAAAUUUUUUUUUUUUUUUUUUUUUUNNNNNNNNNNNNNNNNNNNNNNCCCCCCCCCCCCCCCCCCCCHHHHHHHHHHHHHHHHHHHHHHHHHH w/ Optional([AnyHashable("UIApplicationLaunchOptionsURLSessionKey"): com.rsginc.rmove.sending.Heart])
                                    Sep 20 14:00:20 Craigs-iPhone rMove(libswiftFoundation.dylib)[1257] <Notice>: Launched in: bg:true active:false inactive:false
                                    Sep 20 14:00:20 Craigs-iPhone rMove(UIKitCore)[1257] <Notice>: Warning: Application delegate received call to -application:handleEventsForBackgroundURLSession:completionHandler: but the completion handler was never called.
                                    Sep 20 14:00:20 Craigs-iPhone nsurlsessiond[87] <Notice>: Received signal to deliver pending events for client session: <<private>>.<<private>>
                                    Sep 20 14:00:20 Craigs-iPhone nsurlsessiond[87] <Notice>: <<private>>.<(null)> Lost connection to app -- connection interrupted or invalidated
                                    
                                    Sep 20 14:00:20 Craigs-iPhone assertiond[60] : [rMove:1257] Longest remaining time-limited assertion is  with duration 30.0s
                                    Sep 20 14:00:21 Craigs-iPhone dasd(DuetActivitySchedulerDaemon)[88] : COMPLETED com.apple.CFNetwork-cc-87-1139-Task <67DDB876-180D-4517-B91A-A2115934C80E>...<1>:404391 at priority 10 !
                                    Sep 20 14:00:21 Craigs-iPhone dasd(DuetActivitySchedulerDaemon)[88] : NO LONGER RUNNING com.apple.CFNetwork-cc-87-1139-Task <67DDB876-180D-4517-B91A-A2115934C80E>...<1>:404391 ...Tasks running in group [] are 0!
                                    Sep 20 14:00:33 Craigs-iPhone assertiond[60] : [rMove:1257] Longest remaining time-limited assertion is  with duration 30.0s
                                    Sep 20 14:00:50 Craigs-iPhone dasd(DuetActivitySchedulerDaemon)[88] : com.apple.healthd.awd-submission-manager.heart-daily-analytics:12CF77:[
                                    {name: FileProtectionPolicy, policyWeight: 0.010, response: {Decision: Absolutely Must Not Proceed, Score: 0.00, Rationale: [{classALocked == 1 AND activityFileProtection == }]}}
                                     ], FinalDecision: Absolutely Must Not Proceed}
                                    Sep 20 14:01:04 Craigs-iPhone assertiond[60] : [rMove:1257] Forcing crash report with description: rMove:1257 has active assertions beyond permitted time:
                                     (owner: nsurlsessiond:87)
                                    Sep 20 14:01:04 Craigs-iPhone symptomsd(SymptomEvaluator)[119] : Can't get most elevated app state from dictionary {
                                        BKSApplicationStateExtensionKey = 0;
                                        SBApplicationStateDisplayIDKey = "com.rsginc.rmove";
                                        SBApplicationStateKey = 0;
                                        SBApplicationStateProcessIDKey = 1257;
                                        SBApplicationStateRunningReasonsKey =     (
                                                    {
                                                SBApplicationStateRunningReasonAssertionIdentifierKey = "com.apple.nsurlsessiond.handlesession com.rsginc.rmove.sending.Heart";
                                                SBApplicationStateRunningReasonAssertionReasonKey = 11;
                                            }
                                        );
                                    }
                                    Sep 20 14:01:05 Craigs-iPhone assertiond[60] : Server invalidated 
                                    Sep 20 14:01:05 Craigs-iPhone assertiond[60] : Client relinquished 
                                    Sep 20 14:01:05 Craigs-iPhone powerd[33] : Process assertiond.60 Released SystemIsActive "rMove:1257:87-AF5F00CC-AF9B-432A-8A6E-0731256F86BA [com.apple.nsurlsessiond.handlesession com.rsginc.rmove.sending.Heart] [0x125d4b0a0]" age:00:00:45  id:51539648732 [System: No Assertions]
                                      • Re: Okay to call endBackgroundTask after starting a background session upload?
                                        eskimo Apple Staff Apple Staff (12,305 points)

                                        I was able to grab a log... does this help identify the issue?

                                        Not really.  Understanding this particular problem is going to take more than just a system log, alas.  Moreover, it’s not something that I have to time to do here on DevForums.  If want ongoing help with this investigation, my recommendation is that you open a DTS tech support incident, which will allow me to dedicate more time to your issue.

                                        Share and Enjoy

                                        Quinn “The Eskimo!”
                                        Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                                        let myEmail = "eskimo" + "1" + "@apple.com"

                            • Re: Okay to call endBackgroundTask after starting a background session upload?
                              Vyacheslav P. Level 1 Level 1 (0 points)

                              I faced the same issue. @eskimo, your solutions, and descriptions didn't really help. So, I've requested DTS. It seems, from time time time background tasks lead to a crash. In the console logs, I didn't find the real difference between correct and failed tasks. I hope the support will help me.