Since upgrading my iOS app to Xcode 6.3 (and I admit, doing a few changes to the code), I'm getting a crash on a save to my app's managedObjectContext.
Within Xcode, I get a break on the save call without any information in the debug window. The instruction pointer shows an EXC_BAD_ACCESS.
However, the call-stack shows this 'worrying' information..
Instruments is not helping me. On the device the app crashes without interception. The device logs show similar debug info...
Date/Time: 2015-04-13 11:39:53.861 +0100 Launch Time:
2015-04-13 11:39:32.805 +0100 OS Version: iOS 8.3 (12F69)
Report Version: 105
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype:
KERN_INVALID_ADDRESS at 0x000000001bd5bec8 Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0
Crashed: 0 libobjc.A.dylib 0x0000000197ba8174
objc_release + 20 1 libobjc.A.dylib
0x0000000197ba9720 (anonymous
namespace)::AutoreleasePoolPage::pop(void*) + 560 2
liboainject.dylib 0x0000000100a657dc 0x100a60000 + 22492
3 CoreFoundation 0x00000001865c5070
_CFAutoreleasePoolPop + 24 4 Foundation 0x0000000187504ff8 -[NSAutoreleasePool drain] + 148 5 CoreData
0x00000001863ab6a4 -[_PFManagedObjectReferenceQueue
_processReferenceQueue:] + 2092 6 CoreData 0x00000001863b323c
-[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] + 4704 7 CoreData 0x00000001863b1790 -[NSManagedObjectContext save:] + 160
As you can see, I am saving the data on a viewWillDisappear of my ViewController.
-(void)saveCompanyDetails
{
// Do change to my 'Company' NSManagedObject
...
// Save the Moc
id delegate = [[UIApplication sharedApplication]delegate];
NSManagedObjectContext *managedObjectContext = [delegate managedObjectContext];
__autoreleasing NSError *error = nil;
if( ![managedObjectContext save:&error] ) // CRASH HERE
{
// Report error etc...
}
}
It looks like something's being released out-of-sync. I'm of course, using ARC so it is (in one respect out of my hands). I'm working on the main thread, not any background thread, so am confused as to what it could be.
Can anyone assist with what could be causing this problem, or give pointers as to where to look? At the moment I'm considering going back to xCode 6.2 to see if it rectifies (or rather 'hides' the problem), but this would be a retrograde step and not really solving the problem. I have done code changes since upgrading, but nothing around the core-data area of the app.
Thanks
Related
I have developed an iPad application using Xcode 6.3.2.
I submitted my application to the App Store for review where it was reject due to crash.Following is the crash report from iTunes.
Incident Identifier: 88DD7F94-3382-4241-A0D7-C3E7F6D20737
CrashReporter Key: 9881ae0cc3b3fbfccfd0ce1496d2fa08fec08782
Hardware Model: xxx
Path: /private/var/mobile/Containers/Bundle/Application/FDBBD67F-0EF7-43FB-80CB-8308A10A2D29/Vehicle Visuals.app/Vehicle Visuals
Identifier: com.vehiclevisuals.Vehicle-Visuals
Version: 2.0.0 (1.1.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
Date/Time: 2015-06-12 12:33:57.988 -0700
Launch Time: 2015-06-12 12:22:14.581 -0700
OS Version: iOS 8.3 (12F69)
Report Version: 105
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000195da7bdc 0x195d8c000 + 113628
1 QuartzCore 0x00000001889fdc2c 0x1889ec000 + 72748
2 Vehicle Visuals 0x0000000100126828 0x1000ec000 + 239656
3 Vehicle Visuals 0x0000000100101e80 0x1000ec000 + 89728
4 UIKit 0x0000000189118778 0x1890a4000 + 477048
5 UIKit 0x0000000189116750 0x1890a4000 + 468816
6 UIKit 0x0000000189112000 0x1890a4000 + 450560
7 UIKit 0x00000001890b175c 0x1890a4000 + 55132
8 QuartzCore 0x00000001889f9e18 0x1889ec000 + 56856
9 QuartzCore 0x00000001889f4880 0x1889ec000 + 34944
10 QuartzCore 0x00000001889f4724 0x1889ec000 + 34596
11 QuartzCore 0x00000001889f3eb8 0x1889ec000 + 32440
12 QuartzCore 0x00000001889f3c38 0x1889ec000 + 31800
13 UIKit 0x0000000189137f8c 0x1890a4000 + 606092
14 UIKit 0x0000000189137ef0 0x1890a4000 + 605936
15 CoreFoundation 0x000000018462c2a0 0x18454c000 + 918176
16 CoreFoundation 0x000000018462922c 0x18454c000 + 905772
17 CoreFoundation 0x000000018462955c 0x18454c000 + 906588
18 CoreFoundation 0x00000001845552d0 0x18454c000 + 37584
19 GraphicsServices 0x000000018dc436f8 0x18dc38000 + 46840
20 UIKit 0x000000018911afa8 0x1890a4000 + 487336
21 Vehicle Visuals 0x000000010013a1cc 0x1000ec000 + 319948
22 libdyld.dylib 0x0000000196412a04 0x196410000 + 10756
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
As per the report it crashes on OS Version : iOS 8.3 (12F69).
I tested my app on the all simulators(iPad Air, iPad 2, iPad Retina) with same config(iOS version 8.3 (12F69)) and also tested it on my device (iPad mini) with iOS version 8.3 (12F69), but didn't crashed on my side.
But it crashes on my friend's iPad Air with same iOS version (it gives the same crash report with different invalid address as below)
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype:
KERN_INVALID_ADDRESS at 0x0000000000000020 Triggered by Thread: 0
I don't have the iPad Air so that I could debug using the device.
I also tried to Symbolicated crash report using following command.
xcrun atos -o VehicleVisuals 0x0000000000000020
But it just gives me following hex code.
0x00000020 (in VehicleVisuals)
I following Link for symbolication.
I'm just not being able to recognise where actually is the crash issue.
Please can anybody help me out?
EXC_BAD_ACCESS usually happens because you are sending an Obj-C message to an invalid memory address, what means that you probably are trying to access some deallocated object.
It may be working on other devices because this object is not being released at the same time.
I recently had a similar crash that happened because there was a timer not being invalidated on dealloc, and when the target method was called, that object did no longer exist.
You could try to enable NSZombie objects and see if you find which object is being deallocated. In xCode 6, you can enable them in Product > Scheme > Edit scheme > Diagnostics > Enable Zombie Objects.
Also, there are lots of these kind of errors that NSZombieEnabled can't detect. Unfortunately there is nothing magical to solve it. The second option would be to run your app with instruments (memory leaks specifically) and see if you can get something. If this doesn't work you will have to review your code and check that there are no possibilities that you are trying to access a deallocated object. Hope it helps.
Good luck!
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 at my wits end, I'm getting a weird crash that only happens when the app is launched from Notification Center. Either tapping on a local notification (in the notification side) or a call to extensionContext:openURL:completionHandler (from my Today widget) will launch the app with a customURL scheme.
When the app is running (warm boot), no issues, works just as advertised. When I kill the app (in task switcher) and then try to launch it through Notification Center (cold boot), I get the below crash report.
I've search low and high for anything, can't find it. This only happens on iOS8 devices, iOS7 devices has no issue (with the notification launch, obviously no Today widget)
Has anyone seen this??
thanks!
Date/Time: 2014-10-14 18:16:39.924 -0400
Launch Time: 2014-10-14 18:16:38.667 -0400
OS Version: iOS 8.0.2 (12A405)
Report Version: 105
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000016a4cbeb8
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x0000000195ebbbd0 objc_msgSend + 16
1 UIKit 0x000000018a27d840 -[UIApplication workspaceDidEndTransaction:] + 216
2 FrontBoardServices 0x000000018da7563c __31-[FBSSerialQueue performAsync:]_block_invoke + 24
3 CoreFoundation 0x000000018582a35c __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 16
4 CoreFoundation 0x0000000185829464 __CFRunLoopDoBlocks + 308
5 CoreFoundation 0x0000000185827a88 __CFRunLoopRun + 1752
6 CoreFoundation 0x0000000185755660 CFRunLoopRunSpecific + 392
7 UIKit 0x000000018a05f4fc -[UIApplication _run] + 548
8 UIKit 0x000000018a05a4f4 UIApplicationMain + 1484
9 therichest 0x00000001001caa8c main (main.m:16)
10 libdyld.dylib 0x0000000196516a04 start + 0
Either your code or a third-party library you are using is manually spinning the runloop. This is causing -workspaceDidEndTransaction: to be called re-entrantly and triggers a use after free. If you set a breakpoint on -[NSRunLoop runMode:beforeDate:] and -[NSRunLoop runUntilDate:], it should hit with the guilty code being on the previous stack frame.
While manually spinning the run loop is never recommended, if you can delay doing it until your application finishes starting up (all the launch app delegate calls received) you should avoid hitting this crash.
I'm receiving crash reports (via the excellent Hockey) indicating that I've got a memory problem in some code that's called inside a dispatch_sync block (or at least that's how I'm interpreting the crash report snippet below). I've not been able to recreate this crash on my test devices at all (so strategies like NSZombieEnabled are not helping me). I'm happy to make code changes to make the crash reports more informative (and ultimately solve the underlying issue), I just don't know where to start. Any thoughts?
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0xb000000c
Crashed Thread: 7
...
Thread 7 Crashed:
0 libobjc.A.dylib 0x3979bb66 _objc_msgSend + 6
1 libdispatch.dylib 0x39c898fb _dispatch_barrier_sync_f_invoke + 27
2 App 0x00260f23 __48-[Foo displayLinkCallback]_block_invoke + 147
3 libdispatch.dylib 0x39c85103 _dispatch_call_block_and_release + 11
4 libdispatch.dylib 0x39c894bf _dispatch_async_redirect_invoke + 111
5 libdispatch.dylib 0x39c8a7e5 _dispatch_root_queue_drain + 225
6 libdispatch.dylib 0x39c8a9d1 _dispatch_worker_thread2 + 57
7 libsystem_pthread.dylib 0x39db4dff __pthread_wqthread + 299
The dispatch_sync is provided a static serial queue. Is it possible that the _objc_msgSend is indicating a problem referencing this queue rather than some issue inside the block?
To pre-empt the obvious, I'm seeing no indication of deadlocks in these crash reports.
Update (8th Oct '13)
Adding code as requested (method and variable names changed, but still close to original). I suspect the issue is somewhere around the copying of foo. My hope was that this question would yield stategies for debugging this error. If 'check line by line' is the best strategy for debugging _objc_msgSend crashes inside dispatch_sync block then it's a little sad, but I'll take any help I can get at this point.
Also, I should point out that the crash I am investigating only ever happens on single-core devices and intermittently at that.
- (void) displayLinkCallback
{
dispatch_async(_frameDispatchQueue, ^{
if ([_lock tryLock])
{
dispatch_sync(_renderQueueSerial, ^{
NSObject *fooCopy = nil;
BOOL bar = NO;
// prevents deallocation during subsequent copy
// _foo is set and/or its child objects changed
// many times per second by other threads)
NSObject *foo = _foo;
// copy foo
fooCopy = [foo copy];
bar = [self needsBarGivenFoo:fooCopy];
if (bar)
{
_lastFoo = foo;
[self goFoo:fooCopy];
}
else
{
[self noFoo:fooCopy];
}
});
[_lock unlock];
}
});
}
I would suggest starting your analysis on those references in your source files. This symbolicated crashlog suggests that your crash stems from something in the displayLinkCallback method in the Foo class. You should probably start your investigation there.
It's telling you had a segmentation violation. But it's hard to diagnose further without seeing the source code for that method.
Normally the crash log indicates where this might be happening, but in this case, this is all I am getting. Lets say my main view is A and I have A,B, and C views.
This only happens if I do the following:
Go from A to B to C, go out of app and load up a few other apps. Then return to my app, go back to B, then go back to A (THIS IS WHERE IT CRASHES).
EDIT - I had posted the wrong thread before...here is the correct thread
CRASH LOG:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x4daf03bd
Crashed Thread: 7
Thread 7 name: Dispatch queue: com.apple.root.default-priority
Thread 7 Crashed:
0 libobjc.A.dylib 0x36f22f78 objc_msgSend + 16
1 Foundation 0x33707d04 _NSDescriptionWithLocaleFunc + 44
2 CoreFoundation 0x34f3a96e __CFStringAppendFormatCore + 7998
3 CoreFoundation 0x34eb51d8 _CFStringCreateWithFormatAndArgumentsAux + 68
4 Foundation 0x33707c2e +[NSString stringWithFormat:] + 54
5 MyGreatApp 0x00061028 -[DataAccessor getProducts:div:productType:cat:searchsilver:completion:] (DataAccessor.m:301)
6 MyGreatApp 0x00017196 __36-[products showNationalCategories]_block_invoke_0 (products.m:1688)
7 libdispatch.dylib 0x37886c52 _dispatch_call_block_and_release + 6
8 libdispatch.dylib 0x378927b4 _dispatch_worker_thread2 + 256
9 libsystem_c.dylib 0x35b45df4 _pthread_wqthread + 288
10 libsystem_c.dylib 0x35b45cc8 start_wqthread + 0
Here is line 301 (Note, all the objects going into the string are NSStrings):
NSString *urlStr = [NSString stringWithFormat:#"%#?api_key=%#&device[duid]=%#&division=%#",apiUrl,apiKey, duid, division];
My wild guess is that something is being deallocated in viewDidUnload which is relied upon and not being re-initialized properly. In most cases, viewDidUnload does not get called while testing; and it's the one thing I can think might be happening while you are off in those other apps. Do some double-checking on all of A's properties which get used when the view comes on screen, and double-check that they are non-nil.
I think your callback is being run when a different view controller from the one you were expecting is being presented. I think its first best to work out the faulty string pointer by NSLogging them on separate code lines. Also have you used any _block decorations for those string parameters (or used them twice: both inside and outside the block) -- that would break the retain on them.