Crash that not able to get [closed] - ios

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
thread #1: tid = 0xba03, 0x3a156b26 libobjc.A.dylib`objc_msgSend + 6, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0xa000000c)
frame #0: 0x3a156b26 libobjc.A.dylib`objc_msgSend + 6
frame #1: 0x2fcfc654 CoreFoundation`CFRelease + 556
frame #2: 0x2fd07b44 CoreFoundation`-[__NSArrayM dealloc] + 156
frame #3: 0x3a166b0a libobjc.A.dylib`objc_object::sidetable_release(bool) + 174
frame #4: 0x3a158006 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
frame #5: 0x2fcff980 CoreFoundation`_CFAutoreleasePoolPop + 16
frame #6: 0x3253724c UIKit`_wrapRunLoopWithAutoreleasePoolHandler + 36
frame #7: 0x2fd971cc CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
frame #8: 0x2fd94b70 CoreFoundation`__CFRunLoopDoObservers + 284
frame #9: 0x2fd94eb2 CoreFoundation`__CFRunLoopRun + 730
frame #10: 0x2fcffc26 CoreFoundation`CFRunLoopRunSpecific + 522
frame #11: 0x2fcffa0a CoreFoundation`CFRunLoopRunInMode + 106
frame #12: 0x349de282 GraphicsServices`GSEventRunModal + 138
frame #13: 0x325a3048 UIKit`UIApplicationMain + 1136
frame #14: 0x000ce914 test`main(argc=1, argv=0x27dadd04) + 116 at main.m:16
frame #15: 0x3a663ab6 libdyld.dylib`start + 2
I am trying to solve this crash but I am not able to get the reason for the crash as why it ios coming. Can anybody tell exactly what will be the issue as I am not getting this crash evertime.

This can just help you in sorting out where the crash is happening.
Just add a exception breakpoint so you can catch the error when it crashes.
After adding the breakpoint run the app again and test where it crashes. Almost this finds all the EXC_BAD_ACCESS crashes and puts the breakpoint in the line where the exception is caught.

The Problem could be Something like You are assigning Some text Value to Label or button in some Thread.
If Yes you can't do this. You can only assign the Value in Main thread.

Related

Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread

I am getting this crash after converting an existing UIViewController to Auto Layout and I can't figure out what is causing it. I did search for dispatch_async(dispatch_get_global_queue(...)) calls but none changes layout.
The stack trace is also very unhelpful:
* thread #18: tid = 0x73617, 0x0000000183aa8524 libobjc.A.dylib`objc_exception_throw, stop reason = breakpoint 3.1
* frame #0: 0x0000000183aa8524 libobjc.A.dylib`objc_exception_throw
frame #1: 0x0000000185071100 CoreFoundation`+[NSException raise:format:] + 116
frame #2: 0x0000000185c83894 Foundation`_AssertAutolayoutOnAllowedThreadsOnly + 192
frame #3: 0x0000000185c835d4 Foundation`-[NSISEngine _optimizeWithoutRebuilding] + 76
frame #4: 0x0000000185aceddc Foundation`-[NSISEngine optimize] + 112
frame #5: 0x0000000185c82270 Foundation`-[NSISEngine performPendingChangeNotifications] + 112
frame #6: 0x000000018af23e18 UIKit`-[UIView(Hierarchy) layoutSubviews] + 220
frame #7: 0x000000018b15fff8 UIKit`-[UISlider layoutSubviews] + 192
frame #8: 0x000000018af23a80 UIKit`-[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1196
frame #9: 0x00000001883d19d8 QuartzCore`-[CALayer layoutSublayers] + 148
frame #10: 0x00000001883c64cc QuartzCore`CA::Layer::layout_if_needed(CA::Transaction*) + 292
frame #11: 0x00000001883c638c QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 32
frame #12: 0x00000001883433e0 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 252
frame #13: 0x000000018836aa68 QuartzCore`CA::Transaction::commit() + 512
frame #14: 0x000000018836af34 QuartzCore`CA::Transaction::release_thread(void*) + 660
frame #15: 0x0000000184103fbc libsystem_pthread.dylib`_pthread_tsd_cleanup + 572
frame #16: 0x0000000184103ce4 libsystem_pthread.dylib`_pthread_exit + 200
frame #17: 0x0000000184103378 libsystem_pthread.dylib`_pthread_wqthread + 1504
frame #18: 0x0000000184102d8c libsystem_pthread.dylib`start_wqthread + 4
(lldb)
Is there any way to figure out the exact place that triggered the layout?
Always for change at UI should be work on main thread. also an important subject is you can make an object from view at background thread!!! but for show in view or another changes on it just should be work on main thread, and this subject is main reason for occurrences this problem.
finally for solve this problem you can easily use from 'DispatchQueue'
DispatchQueue.main.async {
// do your work
}
I finally found out the problem after taking another look at the stack trace. The problem was that I was changing the value property of a UISlider instance on a background thread.
But nowhere does it state that you have to change it on the main thread! (Thanks, Apple) Apparently, it seems like UISlider implements the value's setter and forces a layout or something similar.

Crash with pdfTron Integration iOS

I am using pdfTron with iOS. I have successfully integrated PDFTron with my iOS application.
Now I am facing an issue where in if an already made annotation is selected and I try to go back from the view, the application is crashing with EXC_BAD_ACCESS error. I am able to see the previous screen while going back. After the previous screen appears, then the app gets crashed in main. This does not happen when I come back without the annotation being selected.
* thread #1: tid = 0x14c78, 0x0281b3f6 myProject`___lldb_unnamed_symbol40638$$myProject + 22, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000a0)
frame #0: 0x0281b3f6 myProject`___lldb_unnamed_symbol40638$$myProject + 22
frame #1: 0x0250ce31 myProject`___lldb_unnamed_symbol28291$$myProject + 49
frame #2: 0x01bf03f8 myProject`TRN_AnnotIsValid + 40
frame #3: 0x01afd0ba myProject`ObjCPP_PTAnnot_IsValid + 34
frame #4: 0x01a80e0a myProject`-[PTAnnot IsValid] + 32
frame #5: 0x0199d062 myProject`-[AnnotEditTool deselectAnnotation] + 66
frame #6: 0x0198e96b myProject`-[AnnotEditTool willMoveToSuperview:] + 91
frame #7: 0x066e21ce UIKit`__UIViewWillBeRemovedFromSuperview + 305
frame #8: 0x066e1ee3 UIKit`-[UIView(Hierarchy) removeFromSuperview] + 99
frame #9: 0x019a0c09 myProject`-[ToolManager dealloc] + 73
frame #10: 0x06ef413d UIKit`-[UIView(UIKitManual) release] + 142
frame #11: 0x01a7acae myProject`-[PTPDFViewCtrl dealloc] + 588
frame #12: 0x06ef413d UIKit`-[UIView(UIKitManual) release] + 142
frame #13: 0x08e0ca57 CoreFoundation`CFRelease + 727
frame #14: 0x08e2285e CoreFoundation`-[__NSArrayM dealloc] + 142
frame #15: 0x08966060 libobjc.A.dylib`objc_object::sidetable_release(bool) + 238
frame #16: 0x08965361 libobjc.A.dylib`objc_release + 65
frame #17: 0x0896652d libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 371
frame #18: 0x08e2d508 CoreFoundation`_CFAutoreleasePoolPop + 24
frame #19: 0x08e65cdc CoreFoundation`__CFRunLoopRun + 2364
frame #20: 0x08e650e6 CoreFoundation`CFRunLoopRunSpecific + 470
frame #21: 0x08e64efb CoreFoundation`CFRunLoopRunInMode + 123
frame #22: 0x0a49a664 GraphicsServices`GSEventRunModal + 192
frame #23: 0x0a49a4a1 GraphicsServices`GSEventRun + 104
frame #24: 0x0662bbfa UIKit`UIApplicationMain + 160
* frame #25: 0x0013c23c myProject`main(argc=1, argv=0xbffaa928) + 140 at main.m:16
frame #26: 0x09e6ca21 libdyld.dylib`start + 1
The first thing that Annot::IsValid does is check if the pointer is null or not. So if IsValid is crashing, then this means the underlying PDFDoc object has been destroyed, or the underlying pointer is not valid somehow.
First thing to check is if the PDFDoc object is alive or not. If it is destroyed then no objects associated with it should be used.
Or, you deleted the Annotation object earlier somehow, or its underlying pointer got changed. Object references should not be kept around in case they do get moved/deleted. If you want to retain annotations for long term, please see this post.

Swift 2.0 Random EXC_BAD_ACCESS

I'm running into some really strange EXC_BAD_ACCESS crashes which are totally reproducible with the last 2 Xcode 7 Beta versions (including the GM from last night):
When running my application, AFNetworking crashes with an EXC_BAD_ACCESS message in AFURLConnectionOperation.m line 154. More precisely, here is the stacktrace:
thread #1: tid = 0x23b173, 0x000000010b89beaf CoreFoundation`___forwarding___ + 767, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
frame #0: 0x000000010b89beaf CoreFoundation`___forwarding___ + 767
frame #1: 0x000000010b89bb28 CoreFoundation`__forwarding_prep_0___ + 120
* frame #2: 0x0000000105a4507e MyApp`-[AFURLConnectionOperation .cxx_destruct](self=0x00007fc4d873aa20, _cmd=(null)) + 494 at AFURLConnectionOperation.m:154
frame #3: 0x000000010af637bb libobjc.A.dylib`object_cxxDestructFromClass(objc_object*, objc_class*) + 127
frame #4: 0x000000010af6e390 libobjc.A.dylib`objc_destructInstance + 93
frame #5: 0x000000010b94e7c6 CoreFoundation`-[NSObject(NSObject) __dealloc_zombie] + 150
frame #6: 0x00000001087ee9df Foundation`-[NSOperation dealloc] + 89
frame #7: 0x0000000105a3dca2 MyApp`-[AFURLConnectionOperation dealloc](self=0x00007fc4d873aa20, _cmd="dealloc") + 162 at AFURLConnectionOperation.m:216
frame #8: 0x000000010af78afe libobjc.A.dylib`objc_object::sidetable_release(bool) + 232
frame #9: 0x0000000105a31dd1 MyApp`__destroy_helper_block_((null)=0x00007fc4d8b27000) + 65 at AFHTTPRequestOperation.m:0
frame #10: 0x000000010d1226b1 libsystem_blocks.dylib`_Block_release + 128
frame #11: 0x000000010d0a549b libdispatch.dylib`_dispatch_client_callout + 8
frame #12: 0x000000010d08d34b libdispatch.dylib`_dispatch_main_queue_callback_4CF + 1738
frame #13: 0x000000010b8a63e9 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
frame #14: 0x000000010b867939 CoreFoundation`__CFRunLoopRun + 2073
frame #15: 0x000000010b866e98 CoreFoundation`CFRunLoopRunSpecific + 488
frame #16: 0x000000010dd2cad2 GraphicsServices`GSEventRunModal + 161
frame #17: 0x00000001095c9676 UIKit`UIApplicationMain + 171
frame #18: 0x0000000105767d3f MyApp`main(argc=7, argv=0x00007fff5a541620) + 111 at main.m:33
frame #19: 0x000000010d0da92d libdyld.dylib`start + 1
I set enabled Zombie Objects in my scheme and got the following error
*** -[NSMutableURLRequest release]: message sent to deallocated instance 0x7fc4d8acc460
Would any one of you have an idea what is causing the crash? Using Xcode 6 works like a charm but I'd really like to use the new Swift features in my code ...
To answer my own question and leave this here for anyone out there who might be running into the same problem:
Apparently, the Swift 2.0 compiler doesn't like closures being passed an inout parameter. I had a closure in place which could be used to further customize my request which took an object of type NSMutableURLRequest as an inout parameter. Once changing this closure to simply return the request and removing the inout everything works as expected again ...

iOS 8 crashing in a weird pattern

I have spent over a ton of hours working on an app, it works perfectly on iOS 7, both on device and simulator. When I run it on iOS 8, it works perfectly on simulator. But for some reason, when I run it on my iOS 8 device, it starts crashing weirdly. If I implement CLLocation, the app will run smoothly for the first 5 times that I run it. Then it will crash the MOMENT I compile it for the next 5 times. After that 5 times, it starts compiling smoothly again. Then after 5 more times, it crashes on launch again, and the pattern continues.
IE. 1, run. 2. run. 3. run. 4. run. 5. run. 6-10.crash on launch, 11-15, run. 16-20 crash
HOWEVER, when I remove CLLocation, the app runs smoothly, but crashes on every 3rd launch. IE. 1. run. 2. run. 3. crash. 4. run. 5. run 6. crash.
I have been banging my head against the wall for like days without sleep on this. Can someone please explain to me why? For every crash on launch, the only error the console outputs is NSDictionary unknown selector.
I don't want my app to get rejected if Apple reviewers happen to run it at one of the "crash times"
Console Bt
(lldb) bt
* thread #3: tid = 0x12646, 0x00000001983640a8 libobjc.A.dylib`objc_exception_throw, queue = 'com.apple.root.default-qos', stop reason = breakpoint 1.1
frame #0: 0x00000001983640a8 libobjc.A.dylib`objc_exception_throw
frame #1: 0x0000000187d8d094 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 220
frame #2: 0x0000000187d89e48 CoreFoundation`___forwarding___ + 928
frame #3: 0x0000000187c8f08c CoreFoundation`_CF_forwarding_prep_0 + 92
frame #4: 0x0000000188c4f0dc Foundation`-[NSString getExternalRepresentation:extendedAttributes:forWritingToURLOrPath:usingEncoding:error:] + 192
frame #5: 0x0000000188c4f23c Foundation`writeStringToURLOrPath + 72
* frame #6: 0x00000001000c9f1c Blurtalk`+[PFInternalUtils installationId](self=<unavailable>, _cmd=<unavailable>) + 340 at PFInternalUtils.m:307
frame #7: 0x00000001000f0a94 Blurtalk`+[PFNetworkCommandRunner createRequest:](self=0x000000010027d1b8, _cmd=<unavailable>, command=0x0000000170056a70) + 268 at PFNetworkCommandRunner.m:61
frame #8: 0x00000001000f1044 Blurtalk`+[PFNetworkCommandRunner runCommandAsync:inOperation:](self=0x000000010027d1b8, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>) + 196 at PFNetworkCommandRunner.m:132
frame #9: 0x00000001000f1748 Blurtalk`+[PFRetryingCommandRunner runCommandAsync:inOperation:attemptsMade:delay:](self=<unavailable>, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>, attemptsMade=1, delay=<unavailable>) + 92 at PFRetryingCommandRunner.m:42
frame #10: 0x00000001000f16bc Blurtalk`+[PFRetryingCommandRunner runCommandAsync:inOperation:](self=<unavailable>, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>) + 124 at PFRetryingCommandRunner.m:35
frame #11: 0x00000001000f1f80 Blurtalk`+[PFCachedCommandRunner runCommandAsync:inOperation:cachePolicy:maxCacheAge:](self=<unavailable>, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>, cachePolicy=<unavailable>, maxCacheAge=<unavailable>) + 240 at PFCachedCommandRunner.m:82
frame #12: 0x000000010009dcd8 Blurtalk`__48-[BFTask continueWithExecutor:withSuccessBlock:]_block_invoke(.block_descriptor=0x0000000170241e60, task=<unavailable>) + 200 at BFTask.m:335
frame #13: 0x000000010009d730 Blurtalk`__41-[BFTask continueWithExecutor:withBlock:]_block_invoke_2(.block_descriptor=0x000000017807a340) + 32 at BFTask.m:287
frame #14: 0x0000000100338f20 libdispatch.dylib`_dispatch_call_block_and_release + 24
frame #15: 0x0000000100338ee0 libdispatch.dylib`_dispatch_client_callout + 16
frame #16: 0x00000001003459a0 libdispatch.dylib`_dispatch_root_queue_drain + 1272
frame #17: 0x0000000100346f18 libdispatch.dylib`_dispatch_worker_thread3 + 132
frame #18: 0x0000000198b852e4 libsystem_pthread.dylib`_pthread_wqthread + 816
I have been able to reproduce and narrow down your crash using NSZombieEnabled.
My backtrace:
2014-12-30 14:58:26.997 Proto[1398:513570] *** -[CFString getExternalRepresentation:extendedAttributes:forWritingToURLOrPath:usingEncoding:error:]: message sent to deallocated instance 0x170e78fc0
(lldb) bt
* thread #7: tid = 0x7d622, 0x00000001864be440 CoreFoundation`___forwarding___ + 968, queue = 'com.apple.root.default-qos', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1864be440)
* frame #0: 0x00000001864be440 CoreFoundation`___forwarding___ + 968
frame #1: 0x00000001863c2b6c CoreFoundation`_CF_forwarding_prep_0 + 92
frame #2: 0x000000018738a83c Foundation`writeStringToURLOrPath + 72
frame #3: 0x00000001002485bc Proto`+[PFInternalUtils installationId](self=<unavailable>, _cmd=<unavailable>) + 340 at PFInternalUtils.m:308
frame #4: 0x000000010028a944 Proto`+[PFNetworkCommandRunner createRequest:](self=0x000000010054eea8, _cmd=<unavailable>, command=0x0000000170446990) + 308 at PFNetworkCommandRunner.m:62
frame #5: 0x000000010028aef4 Proto`+[PFNetworkCommandRunner runCommandAsync:inOperation:](self=0x000000010054eea8, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>) + 196 at PFNetworkCommandRunner.m:133
frame #6: 0x000000010028b5fc Proto`+[PFRetryingCommandRunner runCommandAsync:inOperation:attemptsMade:delay:](self=<unavailable>, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>, attemptsMade=1, delay=<unavailable>) + 92 at PFRetryingCommandRunner.m:42
frame #7: 0x000000010028b570 Proto`+[PFRetryingCommandRunner runCommandAsync:inOperation:](self=<unavailable>, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>) + 124 at PFRetryingCommandRunner.m:35
frame #8: 0x000000010028be40 Proto`+[PFCachedCommandRunner runCommandAsync:inOperation:cachePolicy:maxCacheAge:](self=<unavailable>, _cmd=<unavailable>, command=<unavailable>, operation=<unavailable>, cachePolicy=<unavailable>, maxCacheAge=<unavailable>) + 248 at PFCachedCommandRunner.m:83
frame #9: 0x00000001001ad038 Proto`__48-[BFTask continueWithExecutor:withSuccessBlock:]_block_invoke(.block_descriptor=0x0000000170446ea0, task=<unavailable>) + 200 at BFTask.m:335
frame #10: 0x00000001001aca90 Proto`__41-[BFTask continueWithExecutor:withBlock:]_block_invoke_2(.block_descriptor=0x0000000171067b40) + 32 at BFTask.m:287
frame #11: 0x0000000100ab8e30 libdispatch.dylib`_dispatch_call_block_and_release + 24
frame #12: 0x0000000100ab8df0 libdispatch.dylib`_dispatch_client_callout + 16
frame #13: 0x0000000100ac59a0 libdispatch.dylib`_dispatch_root_queue_drain + 1280
frame #14: 0x0000000100ac6f18 libdispatch.dylib`_dispatch_worker_thread3 + 132
frame #15: 0x00000001974312e4 libsystem_pthread.dylib`_pthread_wqthread + 816
This is a bug in the Parse SDK, specifically when Parse tries to get device information on an initial install. I suggest you report this bug to Parse directly and point them to this StackOverflow question.
Additional conversation here: Parse Objective C library crashes on [PFInternalUtils installationId]
EDIT: There is an open bug report for this issue here: https://developers.facebook.com/bugs/1548203598729083
you should create an one for all breakpoint that will stop on any exception, please read this article, it is a very useful technique.
http://blog.manbolo.com/2012/01/23/xcode-tips-1-break-on-exceptions
by the way, NSDictionary does not have length, it seems like you made a mistake by confusing it with a NSString object.

Undefined key NSException in UIPickerView iOS7.1

I'm getting an exception in the iOS 7.1 simulator that doesn't appear in 7.0. It appears to be handled somewhere in the core because it only triggers an exception raise breakpoint. It doesn't log to the console or crash. This occurs while scrolling through options in a UIPickerView. There is no meaningful backtrace available (right from UIApplicationMain into objc_exception_throw), but examining the exception during throw in the debugger shows:
[<UIPickerView 0xb9a6700> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _mode.
I searched in my project for mode, setMode:, mode = but I don't think I'm the one setting this. Anyone else run into this? I guess it's okay if it's not crashing the app but it gave me a scare, and I'd rather take action to prevent it from being thrown. If I have some more time I'll try to isolate this in a test project and follow up.
Edit: Better backtrace:
thread #1: tid = 0x10975c, 0x02590909 libc++abi.dylib`__cxa_throw, queue = 'com.apple.main-thread, stop reason = breakpoint 1.2
frame #0: 0x02590909 libc++abi.dylib`__cxa_throw
frame #1: 0x01b1d9fc libobjc.A.dylib`objc_exception_throw + 323
frame #2: 0x020e1fe1 CoreFoundation`-[NSException raise] + 17
frame #3: 0x017ddc7a Foundation`-[NSObject(NSKeyValueCoding) valueForUndefinedKey:] + 282
frame #4: 0x0174adfd Foundation`_NSGetUsingKeyValueGetter + 81
frame #5: 0x0174a437 Foundation`-[NSObject(NSKeyValueCoding) valueForKey:] + 260
frame #6: 0x0d615dff AccessibilityUtilities`-[NSObject(UIAccessibilitySafeCategory) safeValueForKey:] + 43
frame #7: 0x1151c1f6 UIKit`-[UIAccessibilityPickerComponent accessibilityTraits] + 398
frame #8: 0x0d716021 UIAccessibility`-[NSObject(AXPrivCategory) accessibilityAttributeValue:] + 1865
frame #9: 0x0d70a7d7 UIAccessibility`_copyMultipleAttributeValuesCallback + 409
frame #10: 0x0d76c537 AXRuntime`_AXXMIGCopyMultipleAttributeValues + 202
frame #11: 0x0d767e78 AXRuntime`_XCopyMultipleAttributeValues + 473
frame #12: 0x0d7726b4 AXRuntime`mshMIGPerform + 256
frame #13: 0x01fcdca5 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 53
frame #14: 0x01fcd9db CoreFoundation`__CFRunLoopDoSource1 + 523
frame #15: 0x01ff868c CoreFoundation`__CFRunLoopRun + 2156
frame #16: 0x01ff79d3 CoreFoundation`CFRunLoopRunSpecific + 467
frame #17: 0x01ff77eb CoreFoundation`CFRunLoopRunInMode + 123
frame #18: 0x03fea5ee GraphicsServices`GSEventRunModal + 192
frame #19: 0x03fea42b GraphicsServices`GSEventRun + 104
frame #20: 0x007ddf9b UIKit`UIApplicationMain + 1225
frame #21: 0x0004863d [redacted]`main(argc=1, argv=0xbfffef50) + 141 at main.m:16
In my case, on Xcode 6.2 and iOS 8.2, only simulator crashes (but can safely continue). Since _mode is nowhere within our code, it's probably safe to assume there is a simulator bug or misconfiguration.
For now, I am using a category on the offending UIPickerView to get rid of the annoyance:
#import "UIPickerView+FixCrash.h"
#implementation UIPickerView (FixCrash)
#if TARGET_IPHONE_SIMULATOR
- (id)valueForUndefinedKey:(NSString *)key
{
return nil;
}
#endif
#end

Resources