CODEWITHSUNDEEP
iosgrand-central-dispatchios-multithreading
zfgo
zfgo

Reputation: 355

iOS NSInternalInconsistencyException threading violation crash

I have an iOS SDK project that is consumed by third party iOS apps and recently there have been crashes reported around one API in the SDK and the cause is:

threading violation: expected the main thread [name NSInternalInconsistencyException, reason threading violation: expected the main thread]

That API called by the third party app is asynchronous, it does some stuff asynchronously in the background thread and returns a callback to the caller on the main thread.

I am aware that this exception is often raised when doing UI operations in a background thread instead of the main thread.

However, I can't understand why this still happens because in that SDK API before returning the callback to the caller I have the following code to make sure that the caller gets the callback on the main thread:

void runOnMainThread(void (^block)(void)){
if ([NSThread isMainThread]) {
    block();
} else {
    dispatch_async(dispatch_get_main_queue(), block);
}
}

stack trace:

Stack Trace : (
0   CoreFoundation                      0x00000001a154b9ec F3021642-E3C0-33F8-9911-DD303A6056D0 + 1157612
1   libobjc.A.dylib                     0x00000001b58ceb54 objc_exception_throw + 56
2   CoreFoundation                      0x00000001a145a50c F3021642-E3C0-33F8-9911-DD303A6056D0 + 169228
3   Foundation                          0x00000001a2754878 712A564E-5058-3EAC-AF3A-43BBD43D0D7E + 489592
4   FrontBoardServices                  0x00000001b08be614 E42FBC3B-619C-32AB-A210-4A25F8B5373F + 349716
5   FrontBoardServices                  0x00000001b08710a4 E42FBC3B-619C-32AB-A210-4A25F8B5373F + 32932
6   UIKitCore                           0x00000001a3485fdc CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 2088924
7   UIKitCore                           0x00000001a34847e8 CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 2082792
8   UIKitCore                           0x00000001a348456c CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 2082156
9   UIKitCore                           0x00000001a401824c CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 14221900
10  UIKitCore                           0x00000001a3df3c44 CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 11975748
11  UIKitCore                           0x00000001a3df4af0 CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 11979504
12  UIKitCore                           0x00000001a32a37a8 CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 112552
13  UIKitCore                           0x00000001a32a2728 CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 108328
14  UIKitCore                           0x00000001a32a5a18 CC6E5AC7-8248-35F6-8B42-2E25C93DCF0A + 121368
15  third party app                     0x0000000106e81cc0 MySignalHandler + 184
16  libsystem_platform.dylib            0x00000001e90a9d90 3A71914A-C2A7-3514-B519-DF319E7A6E02 + 28048

Is it possible that the caller still gets the callback in a background thread?

Upvotes: 0

Views: 117

Answers (0)

Related Questions