I have an iOS app, and I am getting quite amount of this crash.
And it seems that it is not related to my code. Do you have any idea why the app can crash because of this. Is there something that I can do to prevent these crashes.
Thread 9 Crashed:
1 libobjc.A.dylib _objc_msgSend + 16
2 libdispatch.dylib __dispatch_call_block_and_release + 13
3 libdispatch.dylib __dispatch_queue_drain + 239
4 libdispatch.dylib __dispatch_queue_invoke$VARIANT$mp + 41
5 libdispatch.dylib __dispatch_worker_thread2 + 211
6 libsystem_c.dylib __pthread_wqthread + 295
GCD is used in your app. So..
Bring more detail-info please? code where it's occurred?
May be you need copy block vs retain, may be you need use __block vars correctly. May be something else. Obviously, your object had been captured by block is released and deallocated when happens queue_drain, and after that you call method of the object in other scope, or in the block scope.
Related
Xcode 9 seems to be reporting a lot of Main thread calls to UIApplication properties. Even though the UI is not being updated this is particularly cumbersome due to the extension of logs it produces a default environment.
4 TestApp 0x0000000101c262e0 __39-[ViewController viewDidLoad]_block_invoke + 196
5 libdispatch.dylib 0x0000000102279654 _dispatch_call_block_and_release + 24
6 libdispatch.dylib 0x0000000102279614 _dispatch_client_callout + 16
7 libdispatch.dylib 0x0000000102289008 _dispatch_queue_serial_drain + 716
8 libdispatch.dylib 0x000000010227ce58 _dispatch_queue_invoke + 340
9 libdispatch.dylib 0x000000010228a1c4 _dispatch_root_queue_drain_deferred_wlh + 412
10 libdispatch.dylib 0x00000001022917fc _dispatch_workloop_worker_thread + 868
11 libsystem_pthread.dylib 0x00000001ac6771e8 _pthread_wqthread + 924
12 libsystem_pthread.dylib 0x00000001ac676e40 start_wqthread + 4
If these reporting messages confuse you uncheck them:
Edit Scheme...
Uncheck "Main Thread Checker" in Run > Diagnostics
Check also ARKit template Xcode project Main Thread Checker log console.
If UIApplication or UIApplicationDelegate method is called from another thread you can disable checking thread as in CGN answer, but it will disable this checker completely. You can also subclass what is necessary and call metod of superclass on main thread. This way you can still use Main Thread Sanitizer in other places in code
I'm using FMDB in an iOS app. Recently I have received several crash reports from Apteligent about a crash of FMDB:
0 libdispatch.dylib 0x00000001810ab120 _dispatch_main_queue_callback_4CF + 2904
! 1 myApp 0x00000001001ac840 -[FMDatabaseQueue inDatabase:] (FMDatabaseQueue.m:142)
2 myApp 0x000000010011844c +[DataBaseController insert:withObjects:] (DataBaseController.m:602)
3 myApp 0x0000000100118254 +[DataBaseController insertObjects:withObjects:] (DataBaseController.m:575)
4 myApp 0x0000000100150e80 -[SendManagementBBDD crearySalvarEnvioConSolicitud:EntidadParaEncolar:borrarTrasEnvio:] (SendManagementBBDD.m:686)
5 myApp 0x0000000100150a28 __76-[SendManagementBBDD sendEntitiesAfterDetail:OnComplete:]_block_invoke (SendManagementBBDD.m:615)
6 libdispatch.dylib 0x00000001810a55f0 _dispatch_client_callout + 12
7 libdispatch.dylib 0x00000001810b0b94 _dispatch_sync_f_invoke + 68
8 myApp 0x0000000100150404 -[SendManagementBBDD sendEntitiesAfterDetail:OnComplete:] (SendManagementBBDD.m:563)
9 myApp 0x000000010005c284 __44-[DetailVC startWork:]_block_invoke (DetailVC.m:286)
10 libdispatch.dylib 0x00000001810a5630 _dispatch_call_block_and_release + 20
11 libdispatch.dylib 0x00000001810a55f0 _dispatch_client_callout + 12
12 libdispatch.dylib 0x00000001810b3a88 _dispatch_root_queue_drain + 2136
13 libdispatch.dylib 0x00000001810b3224 _dispatch_worker_thread3 + 108
14 libsystem_pthread.dylib 0x00000001812b9470 _pthread_wqthread + 1088
15 libsystem_pthread.dylib 0x00000001812b9020 start_wqthread + 0
I access to the database from multiple threads. As the documentation says, I have a single instance of FMDatabaseQueue and I share it across all the threads of the app. I'm getting a SEGV_MAPERR crash at the method [FMDatabaseQueue inDatabase:]
This crash happens hardly ever, but I would like to resolve it.
Any ideas what is causing it?
Thank you very much.
Like your other question, this crash seems to be a part of your app code and not Crittercism SDK. If you still believe that this has been caused due to Crittercism, you can create a support ticket by sending an email to support#apteligent.com by mentioning the concerned App ID and the direct crash URL. Be noted that the email support is available for paid customers only.
i have such a report from Crashlytics:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x000000019503fbd0 objc_msgSend + 16
1 CoreFoundation 0x00000001836e5458 CFRelease + 524
2 CoreFoundation 0x00000001836f1a18 -[__NSArrayM dealloc] + 152
3 libobjc.A.dylib 0x0000000195045724 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
4 CoreFoundation 0x00000001836e9074 _CFAutoreleasePoolPop + 28
5 Foundation 0x000000018461a588 -[NSAutoreleasePool release] + 148
6 UIKit 0x00000001882b4460 -[UIApplication _run] + 588
7 UIKit 0x00000001882aefac UIApplicationMain + 1488
Is there anything I can do to catch such an issue? It happens on customer devices so I have no chance to reproduce it.
For crashes like this one, if the crash is reproducible, turn on NSZombies in your project's environment variables. This will keep deallocated objects alive (zombies) and when one of them is messaged, the caller and message will be captured on the crashing object.
Turn it off when done as it can block the memory of the app due to the objects not being released for zombie tracking.
Some of logic code need to be run in background. You need to try debug where is code is error and then add this code
DispatchQueue.main.async(execute: {
// your code
})
It's been answered here: objc_msgSend [__NSArrayM dealloc] crash report sometimes from Crashlytics
Basically, upgrade your Crashlytics framework to past 3.0.9. The crash was in the crash reporting framework itself.
We have an instance of CMMotionManager in our app which we use to get sensor updates at a frequency of 5Hz. Following is the code we use to start motion updates:
[self.motionManager
startDeviceMotionUpdatesUsingReferenceFrame:
CMAttitudeReferenceFrameXMagneticNorthZVertical
toQueue:operationQueue
withHandler:^(CMDeviceMotion *motion, NSError *error) {
if (!error) {
[self doSomethingWithMotion:motion];
} else { ... }
The above method is always invoked on the main thread.
Now, once we are done with our task, we stop motion updates by calling the following method, again on the main thread :
- (void)stopMotionUpdates {
// This might get called on concurrent threads.
// So better using sync block + make it idempotent
#synchronized(self) {
if (_motionManager.deviceMotionActive) {
[_motionManager stopDeviceMotionUpdates];
_prevPoint = nil;
}
}
}
The issue we are facing is that the stopMotionUpdates crashes, that too, only in iPads. We have tested this extensively on iPhones and iPads with different OS versions and we get the crash only on iPads (mini 1,2 and retina/non-retina) for both iOS7 and iOS8. Also, we cannot reproduce the crash on all iPads which we use for testing, but only a few. Following are the crash logs for main and the crashed thread:
Thread : com.apple.main-thread
0 libsystem_kernel.dylib 0x00000001935f1cdc semaphore_wait_trap + 8
1 libdispatch.dylib 0x00000001934fbb3c _dispatch_semaphore_wait_slow + 252
2 CoreMotion 0x0000000186bf67d4 (null)
3 CoreMotion 0x0000000186be3698 (null)
4 MyApp 0x00000001002f7434 -[MyAppMotionManager stopMotionUpdates]
...
...
12 MyApp 0x00000001002e94f8 __getDispatchTimer_block_invoke
13 libdispatch.dylib 0x00000001934f3fd4 _dispatch_client_callout + 16
14 libdispatch.dylib 0x00000001934f5b90 _dispatch_source_invoke + 500
15 libdispatch.dylib 0x00000001934f7180 _dispatch_main_queue_callback_4CF + 244
16 CoreFoundation 0x00000001864fec2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
17 CoreFoundation 0x00000001864fcf6c __CFRunLoopRun + 1452
18 CoreFoundation 0x000000018643dc20 CFRunLoopRunSpecific + 452
19 GraphicsServices 0x000000018c0ddc0c GSEventRunModal + 168
20 UIKit 0x000000018956efdc UIApplicationMain + 1156
21 MyApp 0x00000001000c9850 main (main.m:14)
22 libdyld.dylib 0x000000019350faa0 start + 4
EXC_BREAKPOINT UNKNOWN at 0x0000000186c257ac
Thread : Crashed: Thread
0 CoreMotion 0x0000000186c257ac (null) + 110504
1 CoreMotion 0x0000000186c25774 (null) + 110448
2 CoreMotion 0x0000000186bf3c84 (null)
3 CoreMotion 0x0000000186bf67ec (null)
4 CoreMotion 0x0000000186bf3b80 (null)
5 CoreMotion 0x0000000186c24c48 (null) + 107588
6 CoreMotion 0x0000000186bf67ec (null)
7 CoreMotion 0x0000000186c24ba4 (null) + 107424
8 CoreMotion 0x0000000186be3b9c (null)
9 CoreMotion 0x0000000186bf6860 (null)
10 CoreFoundation 0x00000001864ff680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20
11 CoreFoundation 0x00000001864fe838 __CFRunLoopDoBlocks + 300
12 CoreFoundation 0x00000001864fd0a4 __CFRunLoopRun + 1764
13 CoreFoundation 0x000000018643dc20 CFRunLoopRunSpecific + 452
14 CoreFoundation 0x00000001864932a8 CFRunLoopRun + 112
15 CoreMotion 0x0000000186bf653c (null)
16 libsystem_pthread.dylib 0x000000019368be1c _pthread_body + 168
17 libsystem_pthread.dylib 0x000000019368bd74 _pthread_body
Since we reference self in the motion update handler block, the object shouldn't be deallocated till the entire queue is flushed. Any help is appreciated :)
You might be overloading the main thread.
As a rule of thumb, you should never do anything on the main thread that takes more than or about a second.
The main thread is responsible for running the user interface. If you block the main thread for any significant amount of time, the user interface becomes unacceptably unresponsive.
watchdog — In order to keep the user interface responsive, iOS includes a watchdog mechanism. If your application fails to respond to certain user interface events (launch, suspend, resume, terminate) in time or some operation takes little bit more time on the main thread then the watchdog will kill your application. The amount of time the watchdog gives you is not formally documented, but it's always less.
Any such operation must be done on a background thread and you could easily do it using
dispatch_async
NSOperationQueue
performSelectorInBackground
Hope this helps.
Your crash comes from the #synchronized directive. As you can see the main thread is executing your code in #synchronized. This locks the view controller, from being accessed by any other thread.
The thread that is crashed is for the CoreMotion and I suppose it was trying to give updates on the device motion.
I believe the crash is happening just in some cases when the CoreMotion happens to try to updates in the same time your main thread runs through synchronized.
Where do you define 'operationQueue' there's no self so I'm assuming it's not a class level variable. You want that to be a class property with a strong reference so it isn't deallocated while receiving updates. I've also seen this happen with function scoped variables for the dispatch_queue_t on bluetooth calls.
Memory management would explain the erratic behavior, but you could always try to make iOS more aggressive by opening other apps & a bunch of website tabs on the iPads you've seen this issue on before.
CMMotion updates have got to work in a FIFO order to be accurate so that could explain why you see semaphore_wait_trap in the logs.
I'm getting crash reports of AFNetworking throwing an EXC_BAD_ACCESS KERN_INVALID_ADDRESS:
Thread : Crashed: com.apple.root.default-priority
0 libobjc.A.dylib 0x39e237fa objc_release + 9
1 MY_APP 0x0015ba63 __64-[AFHTTPRequestOperation setCompletionBlockWithSuccess:failure:]_block_invoke (AFHTTPRequestOperation.m:266)
2 MY_APP 0x00163bf7 __47-[AFURLConnectionOperation setCompletionBlock:]_block_invoke (AFURLConnectionOperation.m:301)
3 Foundation 0x3049a2a9 __103+[__NSOperationInternal _observeValueForKeyPath:ofObject:changeKind:oldValue:newValue:indexes:context:]_block_invoke96 + 12
4 libdispatch.dylib 0x3a30b0c3 _dispatch_call_block_and_release + 10
5 libdispatch.dylib 0x3a3107d9 _dispatch_root_queue_drain + 224
6 libdispatch.dylib 0x3a3109c5 _dispatch_worker_thread2 + 56
7 libsystem_pthread.dylib 0x3a43adff _pthread_wqthread + 298
I need help to understand the possible bug. This is something that happens sometimes, actually is very rare and it could be related to a timeout issue when user is using 3G (network can be disconnected while loading data).
I don't post my code because I can't find on the crash log in which file or class this crash happened and I use AFNetworking in a lot of files.
Without any code this is all conjecture but:
Something in the completion block is being accessed after it is deallocated. Commonly, this happens when a network operation isn't cancelled after a view controller is dismissed.