I'm using CocoaPods with a React Native app. I've had various errors when running builds in the Xcode simulator. I don't have issues running it on my device. Here's one that I get when I have breakpoints enabled:
- (void)ensureOnJavaScriptThread:(dispatch_block_t)block
{
RCTAssert(_jsThread, #"This method must not be called before the JS thread is created");
The error here is green (yet breaking, thanks Xcode) and it says com.facebook.react.JavaScript (9): breakpoint 1.2
I get two errors when I disable breakpoints, this is one:
void Instance::loadApplication(std::unique_ptr<RAMBundleRegistry> bundleRegistry,
std::unique_ptr<const JSBigString> string,
std::string sourceURL) {
callback_->incrementPendingJSCalls();
SystraceSection s("Instance::loadApplication", "sourceURL",
sourceURL);
nativeToJsBridge_->loadApplication(std::move(bundleRegistry), std::move(string),
std::move(sourceURL));
}
with the red error on the callback_-> line reading EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
the second is this a signal SIGABRT error from this code:
int main(int argc, char * argv[]) {
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
I think i've fixed that issue before by enabling zombies. When I do that, I see this in the console:
2018-07-11 16:56:08.326 [info][tid:main][RCTRootView.m:293] Running application Mapp ({
initialProps = {
};
rootTag = 11;
})
=================================================================
Main Thread Checker: UI API called on a background thread: -[UIApplication setNetworkActivityIndicatorVisible:]
PID: 34682, TID: 5546845, Thread name: (none), Queue name: com.mixpanel.20e6d2c2b6c431dfecfdfaa100ec0a11.0x7fa94db06940.network, QoS: 0
Backtrace:
4 Mapp 0x0000000103a31dd9 -[MPNetwork updateNetworkActivityIndicator:] + 121
5 Mapp 0x0000000103a2ec09 -[MPNetwork flushQueue:endpoint:] + 985
6 Mapp 0x0000000103a2e7b0 -[MPNetwork flushEventQueue:] + 64
7 Mapp 0x0000000103a10418 __32-[Mixpanel flushWithCompletion:]_block_invoke + 312
8 libdispatch.dylib 0x000000010e3f47ab _dispatch_call_block_and_release + 12
9 libdispatch.dylib 0x000000010e3f57ec _dispatch_client_callout + 8
10 libdispatch.dylib 0x000000010e3fdbe5 _dispatch_queue_serial_drain + 1305
11 libdispatch.dylib 0x000000010e3fe4fa _dispatch_queue_invoke + 328
12 libdispatch.dylib 0x000000010e3fa344 _dispatch_queue_override_invoke + 726
13 libdispatch.dylib 0x000000010e40136c _dispatch_root_queue_drain + 664
14 libdispatch.dylib 0x000000010e401076 _dispatch_worker_thread3 + 132
15 libsystem_pthread.dylib 0x000000010e920169 _pthread_wqthread + 1387
16 libsystem_pthread.dylib 0x000000010e91fbe9 start_wqthread + 13
This to me is unreadable. I don't understand what's wrong. Reminder: this build runs without breaking errors on my device, even when breakpoints are enabled. Is this something I should worry about? Please help!
Because in your code UI API called on a background thread. So please disable the Main Thread Checker of xcode. it will work.
Edit Scheme --- > Diagonstics --- > Runtime API Checking ---> Main
Thread Checker (un-check this setting)
Note: Always update the UI inside below method on a background thread
Or
Put your [UIApplication setNetworkActivityIndicatorVisible:] Method inside DispatchQueue.main.async
DispatchQueue.main.async { // Correct
UIApplication.shared.isNetworkActivityIndicatorVisible = true // in swift 4
[UIApplication setNetworkActivityIndicatorVisible:]// in objective-C
}
https://developer.apple.com/documentation/code_diagnostics/main_thread_checker
Related
Following iOS13 release, I'm testing a hybrid app using Cordova. Launching the camera is very slow and generates the following:
=================================================================
Main Thread Checker: UI API called on a background thread: -[UIImagePickerController init]
PID: 1347, TID: 618928, Thread name: (none), Queue name: com.apple.root.default-qos, QoS: 0
Backtrace:
4 0x0000000100f1bba0 +[CDVCameraPicker createFromPictureOptions:] + 124
5 0x0000000100f15d54 -[CDVCamera showCameraPicker:withOptions:] + 108
6 0x0000000100f15570 __25-[CDVCamera takePicture:]_block_invoke_2 + 336
7 AVFoundation 0x00000001b76178f8 2BC0C357-314E-3AE8-B006-C28528B87512 + 710904
8 TCC 0x00000001b35dfbf8 85A762AF-99DB-3B4C-B24B-09600CC17196 + 7160
9 TCC 0x00000001b35e3de4 85A762AF-99DB-3B4C-B24B-09600CC17196 + 24036
10 libxpc.dylib 0x00000001acfe3804 79A1F1AD-9CB4-3334-91D9-E1ED6B1032A3 + 104452
11 libxpc.dylib 0x00000001acfd72c4 79A1F1AD-9CB4-3334-91D9-E1ED6B1032A3 + 53956
12 libdispatch.dylib 0x000000010109b3b4 _dispatch_client_callout3 + 20
13 libdispatch.dylib 0x00000001010b7000 _dispatch_mach_msg_async_reply_invoke + 392
14 libdispatch.dylib 0x00000001010ada8c _dispatch_kevent_worker_thread + 1436
15 libsystem_pthread.dylib 0x00000001ad0e6adc _pthread_wqthread + 336
16 libsystem_pthread.dylib 0x00000001ad0ecc7c start_wqthread + 8
Xcode 10.3
cordova-plugin-camera version 4.1.0
running on iPhone X, iOS13
Eventually the camera opens and allows me to take a photo but the UI is not displayed correctly afterwards. I've tried creating a brand new app with only the camera plugin added and the same thing happens.
How this can be resolved?
It would seem that UIImagePickerController needs to be called in the UI Thread.
Fortunately, the code is already ready for that change!
Just move the cameraPicker init section into the main thread section:
dispatch_async(dispatch_get_main_queue(), ^{
// UI MainThread execution
CDVCameraPicker* cameraPicker = [CDVCameraPicker createFromPictureOptions:pictureOptions];
weakSelf.pickerController = cameraPicker;
cameraPicker.delegate = weakSelf;
cameraPicker.callbackId = command.callbackId;
// we need to capture this state for memory warnings that dealloc this object
cameraPicker.webView = weakSelf.webView;
...
}
D.
I use crashlytics to get the crashes of my app, i am currently Crashlytics version: 3.9.3. Some users are getting a crash that I cannot seem to repro on my machine. This is the logs from Fabric:
Crashed: com.apple.root.default-qos
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00004a4b9a43bec8
#37. Crashed: com.apple.root.default-qos
0 libobjc.A.dylib 0x7fff6b43d184 objc_release + 36
1 MyApp 0x10805ad2d __66-[AppManager getCountriesDelegate:]_block_invoke (AppManager.m:1412)
2 libdispatch.dylib 0x7fff6c006591 _dispatch_call_block_and_release + 12
3 libdispatch.dylib 0x7fff6bffed50 _dispatch_client_callout + 8
4 libdispatch.dylib 0x7fff6c00bc61 _dispatch_queue_override_invoke + 880
5 libdispatch.dylib 0x7fff6c000941 _dispatch_root_queue_drain + 515
6 libdispatch.dylib 0x7fff6c0006ed _dispatch_worker_thread3 + 101
7 libsystem_pthread.dylib 0x7fff6c2c31ca _pthread_wqthread + 1387
8 libsystem_pthread.dylib 0x7fff6c2c2c4d start_wqthread + 13
- (void) getCountriesDelegate:(id<AppManagerDelegate>)delegate
{
__weak __typeof(id<AppManagerDelegate>) weakDelegate = delegate;
__weak __typeof(self) weakSelf = self;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ //my function definition
});
There are multiples reasons why you can get a EXC_BAD_ACCESS KERN_INVALID_ADDRESS error code. Appel's documentation says:
EXC_BAD_ACCESS/KERN_INVALID_ADDRESS — This is caused by the thread
accessing unmapped memory. It may be triggered by either a data access
or an instruction fetch; the Thread State section describes how to
tell the difference.
You should look deeply at your class AppManager. As the crashlog said's the crash occurs at line 1412 of file AppManager.m in the method getCountriesWithRespectToPurposeAndFavoriteDelegate:.
Main Thread Checker: UI API called on a background thread: -[UIView init]
PID: 460, TID: 62011, Thread name: (none), Queue name: com.apple.root.background-qos, QoS: 9
Backtrace:
4 IQKeyboardManagerSwift 0x00000001025c8274 _T0So11UITextFieldCABycfcTO + 28
5 IQKeyboardManagerSwift 0x00000001025a8360 _T0So11UITextFieldCABycfC + 68
6 IQKeyboardManagerSwift 0x00000001025a7e90 _T022IQKeyboardManagerSwift0aB0CACycfc + 5196
7 IQKeyboardManagerSwift 0x00000001025a838c _T022IQKeyboardManagerSwift0aB0CACycfcTo + 28
8 IQKeyboardManagerSwift 0x00000001025a6a3c _T022IQKeyboardManagerSwift0aB0CACycfC + 32
9 IQKeyboardManagerSwift 0x00000001025c5920 globalinit_33_1804EA4A44CDC62F5B66EAD58B4692DC_func2 + 24
10 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
11 libdispatch.dylib 0x00000001043e617c dispatch_once_f + 120
12 IQKeyboardManagerSwift 0x000000010259c4cc _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ6StaticL_V02kbB0ACfau + 56
13 IQKeyboardManagerSwift 0x000000010259c46c _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ + 24
14 eBeePartners 0x0000000100c9ef7c _T012eBeePartners11AppDelegateC11applicationSbSo13UIApplicationC_s10DictionaryVySC0F16LaunchOptionsKeyVypGSg022didFinishLaunchingWithI0tFyycfU_ + 52
15 eBeePartners 0x0000000100bd18c0 _T0Ix_IyB_TR + 48
16 libdispatch.dylib 0x00000001043e549c _dispatch_call_block_and_release + 24
17 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
18 libdispatch.dylib 0x00000001043f6cd8 _dispatch_root_queue_drain + 1004
19 libdispatch.dylib 0x00000001043f6880 _dispatch_worker_thread3 + 136
20 libsystem_pthread.dylib 0x0000000181dab130 _pthread_wqthread + 1268
21 libsystem_pthread.dylib 0x0000000181daac30 start_wqthread + 4
2017-09-22 12:36:11.268059+0800 eBeePartners[460:62011] [reports] Main Thread Checker: UI API called on a background thread: -[UIView init]
PID: 460, TID: 62011, Thread name: (none), Queue name: com.apple.root.background-qos, QoS: 9
Backtrace:
4 IQKeyboardManagerSwift 0x00000001025c8274 _T0So11UITextFieldCABycfcTO + 28
5 IQKeyboardManagerSwift 0x00000001025a8360 _T0So11UITextFieldCABycfC + 68
6 IQKeyboardManagerSwift 0x00000001025a7e90 _T022IQKeyboardManagerSwift0aB0CACycfc + 5196
7 IQKeyboardManagerSwift 0x00000001025a838c _T022IQKeyboardManagerSwift0aB0CACycfcTo + 28
8 IQKeyboardManagerSwift 0x00000001025a6a3c _T022IQKeyboardManagerSwift0aB0CACycfC + 32
9 IQKeyboardManagerSwift 0x00000001025c5920 globalinit_33_1804EA4A44CDC62F5B66EAD58B4692DC_func2 + 24
10 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
11 libdispatch.dylib 0x00000001043e617c dispatch_once_f + 120
12 IQKeyboardManagerSwift 0x000000010259c4cc _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ6StaticL_V02kbB0ACfau + 56
13 IQKeyboardManagerSwift 0x000000010259c46c _T022IQKeyboardManagerSwift0aB0C06sharedB0ACyFZ + 24
14 eBeePartners 0x0000000100c9ef7c _T012eBeePartners11AppDelegateC11applicationSbSo13UIApplicationC_s10DictionaryVySC0F16LaunchOptionsKeyVypGSg022didFinishLaunchingWithI0tFyycfU_ + 52
15 eBeePartners 0x0000000100bd18c0 _T0Ix_IyB_TR + 48
16 libdispatch.dylib 0x00000001043e549c _dispatch_call_block_and_release + 24
17 libdispatch.dylib 0x00000001043e545c _dispatch_client_callout + 16
18 libdispatch.dylib 0x00000001043f6cd8 _dispatch_root_queue_drain + 1004
19 libdispatch.dylib 0x00000001043f6880 _dispatch_worker_thread3 + 136
20 libsystem_pthread.dylib 0x0000000181dab130 _pthread_wqthread + 1268
21 libsystem_pthread.dylib 0x0000000181daac30 start_wqthread + 4
2017-09-22 12:36:22.758673+0800 eBeePartners[460:61967] [BoringSSL] Function nw_protocol_boringssl_input_finished: line 1389 Peer disconnected during the middle of a handshake. Sending errSSLFatalAlert(-9802) alert
2017-09-22 12:36:22.813732+0800 eBeePartners[460:61967] TIC TCP Conn Failed [2:0x1c0166900]: 3:-9802 Err(-9802)
2017-09-22 12:36:22.848609+0800 eBeePartners[460:61719] [MC] Lazy loading NSBundle MobileCoreServices.framework
2017-09-22 12:36:22.854700+0800 eBeePartners[460:61719] [MC] Loaded MobileCoreServices.framework
2017-09-22 12:36:22.864960+0800 eBeePartners[460:61719] [MC] System group container for systemgroup.com.apple.configurationprofiles path is /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles
2017-09-22 12:36:22.898137+0800 eBeePartners[460:62011] *** Assertion failure in void _UIPerformResizeOfTextViewForTextContainer(NSLayoutManager *, UIView<NSTextContainerView> *, NSTextContainer *, NSUInteger)(), /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIFoundation/UIFoundation-543/UIFoundation/TextSystem/NSLayoutManager_Private.m:1619
2017-09-22 12:36:23.117424+0800 eBeePartners[460:62011] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Only run on the main thread!'
*** First throw call stack:
(0x18217fd38 0x181694528 0x18217fc0c 0x182b0ec90 0x18c65a70c 0x18c65a194 0x18c689e4c 0x18c689b08 0x18c6b3f88 0x18b8ebf28 0x18b5b1218 0x18c1e697c 0x18b6613ec 0x1025c8274 0x1025a8360 0x1025a7e90 0x1025a838c 0x1025a6a3c 0x1025c5920 0x1043e545c 0x1043e617c 0x10259c4cc 0x10259c46c 0x100c9ef7c 0x100bd18c0 0x1043e549c 0x1043e545c 0x1043f6cd8 0x1043f6880 0x181dab130 0x181daac30)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)
How to debug this code?
I also had this error ONLY AFTER upgrading to Xcode9/Swift4. As mentioned in comments, the reason is calling ui-operations in background thread. I don't know why it has been working until upgrading.
How to debug
You are seeing this error on Xcode which process frozen by debugger, right? Then, the left side panel (called "debug navigator") is showing call stack and indicating the line where the app crashed. You can click one of them and get the code.
In my case
The cause of error is performSegue attempted to run on the main thread in my case.
func downloadHandler() {
DispatchQueue.global(qos: .default).async(execute: {
DispatchQueue.main.async(execute: {
self.labelMessage.text = "Unzipping downloaded data..."
})
/* Unzipping something... */
// WRONG: This causes error
// self.performSegue(withIdentifier: "toViewController", sender: nil)
// FIXED: performSegue should be run on main thread.
DispatchQueue.main.async(execute: {
self.performSegue(withIdentifier: "toViewController", sender: nil)
})
})
}
Double check your DispatchQueue. It would be better to start at where debugger stopped.
I get the following crash:
Exception Type: 00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread: 0
Application Specific Information:
com.[app name].[app name] failed to scene-update in time
Elapsed total CPU time (seconds): 5.050 (user 5.050, system 0.000), 24% CPU
Elapsed application CPU time (seconds): 0.044, 0% CPU
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib 0x0000000195018e48 semaphore_wait_trap + 8
1 libdispatch.dylib 0x0000000194efbf3c _dispatch_semaphore_wait_slow + 252
2 CFNetwork 0x00000001832a2220 CFURLConnectionSendSynchronousRequest + 284
3 CFNetwork 0x00000001832c27c8 +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 116
4 Foundation 0x0000000184726358 -[NSData(NSData) initWithContentsOfURL:options:error:] + 308
5 Foundation 0x0000000184726204 +[NSData(NSData) dataWithContentsOfURL:options:error:] + 72
6 [app name] 0x00000001000b1a30 0x100090000 + 137776
7 [app name] 0x00000001001e3f44 0x100090000 + 1392452
8 libdispatch.dylib 0x0000000194eed990 _dispatch_call_block_and_release + 20
9 libdispatch.dylib 0x0000000194eed950 _dispatch_client_callout + 12
10 libdispatch.dylib 0x0000000194ef2208 _dispatch_main_queue_callback_4CF + 1604
11 CoreFoundation 0x00000001838962e8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
12 CoreFoundation 0x0000000183894390 __CFRunLoopRun + 1488
13 CoreFoundation 0x00000001837c11f0 CFRunLoopRunSpecific + 392
14 GraphicsServices 0x000000018cae36f8 GSEventRunModal + 164
15 UIKit 0x0000000188152108 UIApplicationMain + 1484
16 [app name] 0x00000001000dd2ac 0x100090000 + 316076
17 libdyld.dylib 0x0000000194f1aa04 start + 0
On the following code:
#try {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0ul), ^(void) {
NSData* data = [NSData dataWithContentsOfURL:xxxxxxx options:NSDataReadingUncached error:&error];
...
[self.buffer performSelectorOnMainThread:#selector(addObject:) withObject:data waitUntilDone:YES];
}
#catch (NSException* error) {
NSLog(#"error: %#", error);
}
Yes there is a failure block too, but I simplified the code to the essence, the pure code that causes the crash.
This code runs hundreds of times per hour without any problem. But every now and then it crashes. Always the same crash (like the one above). First, the app freezes, then it crashes. The catch-block is never executed.
The performSelectorOnMainThread uses an object. And that object is added (in the main thread) to an NSMutableArray (self.buffer is an NSMutableArray). I know that NSMutableArrays are not thread-safe and that's why I perform them on the main thread. For waitUntilDone I use YES to prevent the thread from ending before the object is inserted. I used NO too, but that crashes constantly.
Does anyone have an idea why this crash happens? And do you perhaps have a solution for me to prevent this?
Thanks a lot.
You are doing network i/o on the main thread while updating the UI. This takes too long. Don't do that on the main thread. Instead, use an asynchronous way to run the URL fetch and cache the result so it can be used by the next user interface update.
More information:
https://developer.apple.com/library/ios/qa/qa1693/_index.html
Writing to the array on the main thread does not make it thread safe. Use a dedicated dispatch_queue to control access to the nsmutablearray instead, both read and write operations.
https://stackoverflow.com/a/4607664/573988
I have received a couple of crash reports, and the only thing I can see in common is that they are both iPhone 5. I can't reproduce the crash on iPhone 5s or 6 so I I assumed it was a 64/32 bit issue. However the code also runs fine on an iPhone 4s running iOS 7.
The crash is happening on the last line here:
IMP imp = [self.delegate methodForSelector:aSelector];
id (*func)(id, SEL, id) = (void *)imp;
func(self.delegate, aSelector, self);
To be perfectly honest, I don't understand these 3 lines of code. I found them to overcome a compiler warning may cause a leak because its selector is unknown when using [self.delegate performSelector:aSelector withObject:self];
When I push an update using performSelector it doesn't crash.
I need to pass an argument of self along with the selector which is why I used IMP and added self as the third argument which is how I read it should be done.
The actual crash log doesn't reveal much:
Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000100 Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x30ca26b8 objc_retain + 7
1 Timeout 0x0009e2a1 __50-[BaseOperation finishedSuccessfullyWithSelector:]_block_invoke_2 (BaseOperation.m:47)
2 libdispatch.dylib 0x311e87bb
_dispatch_call_block_and_release + 10
3 libdispatch.dylib 0x311efe8b _dispatch_after_timer_callback + 66
4 libdispatch.dylib 0x311e87a7 _dispatch_client_callout + 22
5 libdispatch.dylib 0x311f9253 _dispatch_source_latch_and_call + 626
6 libdispatch.dylib 0x311ea2ed _dispatch_source_invoke + 212
7 libdispatch.dylib 0x311ebe1f _dispatch_main_queue_callback_4CF + 330
8 CoreFoundation 0x234a39d1 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
9 CoreFoundation 0x234a20d1 __CFRunLoopRun + 1512
10 CoreFoundation 0x233f0211 CFRunLoopRunSpecific + 476
11 CoreFoundation 0x233f0023 CFRunLoopRunInMode + 106
12 GraphicsServices 0x2a7e90a9 GSEventRunModal + 136
13 UIKit 0x269fc1d1 UIApplicationMain + 1440
14 Timeout 0x000a265b main (main.m:14)
Is there anyone that can shed some light on this?
Thanks
EDIT ----
I am now also seeing crashes on iPad 3 (iOS 8.1.2) & iPhone 5 (iOS 8.1). Yet still can't reproduce it myself, I also tried an iPod (iOS 8.1) and iPad mini retina (iOS 8.1.3). This is really bugging me (Pun intended).
EDIT 2 ----
I've added some Crashlytics logs to log self.delegate self imp & func and they all appear to be fine! So why does the very next line crash?
0 | 00:01:33:665 | $ __50-[BaseOperation finishedSuccessfullyWithSelector:]_block_invoke_2 : connectComplete:
1 | 00:01:33:665 | $ delegate: <BaseMenuViewController: 0x17e5e780>
2 | 00:01:33:666 | $ self: <ConnectOperation_Virgin: 0x1902a490>{name = '(null)'}
3 | 00:01:33:667 | $ imp: 0xaa345
4 | 00:01:33:667 | $ func: 0xaa345
I had the same problem, working code 6 months ago now crashes, fixed it with those changes :
//old code
IMP imp = [_target methodForSelector:_action];
id (*func)(id, SEL, id) = (void *)imp;
func(_target, _action, params);
//replaced by
void (*imp)(id, SEL, id) = (void(*)(id,SEL,id))[_target methodForSelector:_action];
if( imp ) imp(_target, _action, params);