nib objects gets bad access even though it have been retained by property - iphone

I have nib file having lots of UIViews(More than 100), Also I am creating 500+ UIViews using Code.
Just FYI, Application is kind of Game board with Blocks.
Problem, Randomly application get crashed on nib objects while playing game. I am not able to make test case. But I can say that Application crashed on Nib objects(IBOutlet) only.
each time it throughs bad access on nib's IBOutlet only.
I tried by making IBOutlet property with retain. also synthesize properly, but getting the same problem randomly.
Please help me to manage nib objects.
Exact Error Message was : EXC_BAD_ACCESS
Here is Stacktrace
libobjc.A.dylib 0x3995e5aa objc_msgSend + 9
1WWS 0x00064437 0x5a000 + 42039
2WWS 0x00063b5d 0x5a000 + 39773
3Foundation 0x37df7539 + 200
4Foundation 0x37deedb9 + 840
5Foundation 0x37e673db + 102
6libdispatch.dylib 0x370b211f + 10
7libdispatch.dylib 0x370b14b7 + 22
8libdispatch.dylib 0x370b61bd + 224
9CoreFoundation 0x34d57f3b + 1290
10CoreFoundation 0x34ccaebd CFRunLoopRunSpecific + 356
11CoreFoundation 0x34ccad49 CFRunLoopRunInMode + 104
12GraphicsServices 0x3261d2eb GSEventRunModal + 74
13UIKit 0x342a72f9 UIApplicationMain + 1120
14WWS 0x0005b09f 0x5a000 + 4255

One way to test whether IBoutlet causing problem or not is, Disconnect all IBoutlet view. Instantiate them in view didLoad method and try running your app. If app still crashes then consider it is memory issue.
If app is not crashing then it is might be IBoutlet issue only.
Another way is to use Instruments tool.
Use product -> Analyze to check any memory leaks in your code.
Run product -> profile -> Leaks tool check runtime leaks.

Related

What can cause this SIGSEGV error?

I received a crash log that I cannot explain. I have searched around and it appears that the SIGSEGV has something to do with memory. But in my case there is nothing of my own code except for the main.m in the stacktrace. Also it doesn't seem to symbolicate any of the system libraries.
The crash so far only happened on one iPhone. On other phones I haven't been able to reproduce it. Right now I'm completely stuck and don't know where to continue so if anyone has seen something like this before it would be good to hear their problem and resolution.
The crash log:
Incident Identifier: TODO
CrashReporter Key: TODO
Hardware Model: iPhone4,1
OS Version: iPhone OS 6.1.3 (10B329)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x41fd5903
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x3b0b9564 0x3b0b6000 + 13668
1 libobjc.A.dylib 0x3b0bb1d7 0x3b0b6000 + 20951
2 CoreFoundation 0x33396605 0x332d4000 + 796165
3 CoreFoundation 0x3339635d 0x332d4000 + 795485
4 libobjc.A.dylib 0x3b0bea65 0x3b0b6000 + 35429
5 libc++abi.dylib 0x3ab0b07b 0x3ab0a000 + 4219
6 libc++abi.dylib 0x3ab0b114 0x3ab0a000 + 4372
7 libc++abi.dylib 0x3ab0c599 0x3ab0a000 + 9625
8 libobjc.A.dylib 0x3b0be9d1 0x3b0b6000 + 35281
9 CoreFoundation 0x332dcf21 0x332d4000 + 36641
10 CoreFoundation 0x332dcd49 0x332d4000 + 36169
11 GraphicsServices 0x36eb52eb 0x36eb0000 + 21227
12 UIKit 0x351f2301 0x3519b000 + 357121
13 Stylbar 0x0007109f main (main.m:21)
Edit 3th of May:
The crash log is sent by a user. I haven't been able to reproduce the issue myself unfortunately, which is why it's so difficult for me to figure out what went wrong with just this crash log.
It appeared to have happened about 15 times in a row for the same user when opening a certain view controller. The view controller does several calls to a server to load a post, comments and images and profile pictures. All the code that's executed when this view controller is opened is probably over 2000 lines of code (excluding the RestKit and SBWebImage libraries that are used within this code). Posting that code here wouldn't help anyone I'm afraid.
The most simple and useful way to spend your time hunting for the cause of the crash is to look at your code and focus on places where UIKit has a delegate that points back into your code. For example, I found that the most common place this sort of thing would show up was in UITableView. The reason these problems are so hard to track down is that they might only happen in a low memory situation or in some uncommon UI condition that is very hard to reproduce. It is better to just do a code review and make sure that delegate that are set to point to your classes are set back to nil in your own object destructors. If you have many developers, it is often better to work on some higher level abstractions like a generic table and cell class that is used throughout the project than to have every developer coding up a UITableView and making mistakes like forgetting to nil out the delegate that are very difficult to find.
SIGSEGV is a problem the occurs when your application tries to access an address of memory that doesn't exists or some address where is already reserved to another program. I have the same issue with an application right now but I have to review my code to figure it out better. One clue for this kind of problem could be something equivalent to this (found in wikipedia):
#include <stdlib.h>
int main(void)
{
char p = NULL; / p is a pointer to char that initializes poiting to "nowhere"*/
* p = 'x'; /* Tries to save the char 'x' in 'no address'*/
return 0;
}
I hope this can help someone.

Why do i get exc bad access in cases when object is not nil?

I have an app that receives remote notifications. My view controller that is shown after push has a tableview. App crashes very randomly (1 in 20 tries) at line setting frame:
if (!myTableView) {
NSLog(#"self.myTableView is nil");
}
myTableView.frame=CGRectMake(0, 70, 320, 376);
This only happens when i open the app, then open some other apps and then receive the push notification. I guess it has something to do with memory. I use ARC (ios 5). The strange thing is that nslog is not displayed, so tableview is not nil.
Crash log:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x522d580c
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x352b1f7e objc_msgSend + 22
1 Foundation 0x37dc174c NSKVOPendingNotificationCreate + 216
2 Foundation 0x37dc1652 NSKeyValuePushPendingNotificationPerThread + 62
3 Foundation 0x37db3744 NSKeyValueWillChange + 408
4 Foundation 0x37d8a848 -[NSObject(NSKeyValueObserverNotification) willChangeValueForKey:] + 176
5 Foundation 0x37e0ca14 _NSSetPointValueAndNotify + 76
6 UIKit 0x312af25a -[UIScrollView(Static) _adjustContentOffsetIfNecessary] + 1890
7 UIKit 0x312cca54 -[UIScrollView setFrame:] + 548
8 UIKit 0x312cc802 -[UITableView setFrame:] + 182
9 POViO 0x000913cc -[FeedVC viewWillAppear:] (FeedVC.m:303)
Dealloc is not called because it is not logged:
- (void)dealloc {
NSLog(#"dealloc");
}
You are having memory issues. Your tableView is reaching a retain count of zero; so although a pointer to the tableView still exists, the system has trashed the object at that actual address, hence the EXC_BAD_ACCESS.
It's possible that your UI that showed the tableView is hidden and therefore unloaded, but you've left some logic that assumes the table view still exists when it doesn't.
It's hard to debug what's going on without seeing more of the project. The best thing for you to do is have a careful look at the design of your application and UI flow. What would be causing the UI to be be released? How are you entering the code that assumes that part of the UI is still there?
N.B. Sending messages to a nil reference would not generate any errors; this is by language design.
I found the solution here:
Using ARC and UITableViewController is throwing Observation info was leaked, and may even become mistakenly attached to some other object
Seems pull to refresh (subview to tableview) was causing problems.
Do not change frame directly,do something like this.
CGRect frame = self. myTableView.frame;
frame.x =something;
frame.y=something;
myTableView.frame=frame;
and let me know.

Terminating app due to uncaught exception 'NSUnknownKeyException' [duplicate]

This question already has answers here:
Xcode - How to fix 'NSUnknownKeyException', reason: … this class is not key value coding-compliant for the key X" error?
(79 answers)
Closed 7 years ago.
I'm using a tutorial to write a fairly simple app. I copied the app to my work computer today. It was working perfectly on my laptop last night, but today I get this error. I tried gutting nearly all of the code, and even deleted everything in the didFinishLaunchingWithOptions function, but I still get this error. I don't even have a navBar declared anywhere! I assume there's some kind of project or file setting outside of the code that is the problem?
2011-11-22 14:39:32.294 LetsEat[15320:b603] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<LetsEatAppDelegate 0x5a824a0> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key navBar.'
*** Call stack at first throw:
(
0 CoreFoundation 0x00fa45a9 __exceptionPreprocess + 185
1 libobjc.A.dylib 0x010f8313 objc_exception_throw + 44
2 CoreFoundation 0x00fa44e1 -[NSException raise] + 17
3 Foundation 0x0079f677 _NSSetUsingKeyValueSetter + 135
4 Foundation 0x0079f5e5 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 285
5 UIKit 0x0021b30c -[UIRuntimeOutletConnection connect] + 112
6 CoreFoundation 0x00f1a8cf -[NSArray makeObjectsPerformSelector:] + 239
7 UIKit 0x00219d23 -[UINib instantiateWithOwner:options:] + 1041
8 UIKit 0x0021bab7 -[NSBundle(UINSBundleAdditions) loadNibNamed:owner:options:] + 168
9 UIKit 0x0002117a -[UIApplication _loadMainNibFile] + 172
10 UIKit 0x00021cf4 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 291
11 UIKit 0x0002c617 -[UIApplication handleEvent:withNewEvent:] + 1533
12 UIKit 0x00024abf -[UIApplication sendEvent:] + 71
13 UIKit 0x00029f2e _UIApplicationHandleEvent + 7576
14 GraphicsServices 0x011dd992 PurpleEventCallback + 1550
15 CoreFoundation 0x00f85944 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
16 CoreFoundation 0x00ee5cf7 __CFRunLoopDoSource1 + 215
17 CoreFoundation 0x00ee2f83 __CFRunLoopRun + 979
18 CoreFoundation 0x00ee2840 CFRunLoopRunSpecific + 208
19 CoreFoundation 0x00ee2761 CFRunLoopRunInMode + 97
20 UIKit 0x000217d2 -[UIApplication _run] + 623
21 UIKit 0x0002dc93 UIApplicationMain + 1160
22 LetsEat 0x00001c99 main + 121
23 LetsEat 0x00001c15 start + 53
)
terminate called throwing an exceptionCurrent language: auto; currently objective-c
(gdb)
EDIT: This is the top of my delegate.m file. As you can see it's all boilerplate:
#import "LetsEatAppDelegate.h"
//#import "ItemsViewController.h"
#implementation LetsEatAppDelegate
#synthesize window = _window;
#synthesize managedObjectContext = __managedObjectContext;
#synthesize managedObjectModel = __managedObjectModel;
#synthesize persistentStoreCoordinator = __persistentStoreCoordinator;
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// Override point for customization after application launch.
[self.window makeKeyAndVisible];
return YES;
}
I removed every other file in the project and still get this error.
EDIT 2
As it now stands, I only get this error on my work machine. The exact same files run perfectly on my home laptop. Same version of XCode (4.2.1)
Reset Content and Setting didn't work.
Here's what wasted 2 hrs of my late night time:
I had connected an UIControl outlet in the interface builder to the IBOutlet in the xib's owner. For some reason, the IBOutlet was deleted from the owner, but the reference to the outlet remained dangling in the xib. This would always give me the error
"Terminating app due to uncaught exception 'NSUnknownKeyException'"
Lesson learnt: When deleting any outlets for vars in the implementation, make sure to unhook the respective connection in the IB
Update: (26 Jan 2015)
There's a good reason why the Interface Builder or the nibs behave this way, and I realized the why, today.
If you have an IBOutlet in TheBaseClass, and you have a nib or scene in the storyboard for a TheSubClass, there are two ways (hacks) available for you to connect this outlet:
Under the Identity Inspector, name the "Custom Class" identifier to TheBaseClass, connect the outlet, then set the Class name in the "Custom Class" section to TheSubclass
Add the IBOutlet in your TheSubclass code, connect it to the ui element in the nib, add the IBOutlet code in TheBaseClass, delete that code in TheSubClass
When I came across this answer it just fell in place, as to why Apple would let this dangling reference problem remain as is. Because, this is not a bug. This is a feature.
Fixed - went to iOS Simulator > Reset Content and Setting
I had this issue and found that I had set the 'Main Interface' and it was causing an issue.
To change this setting click on your project (in the left hand file browser). The center area should now display the 'Summary' of settings for your project. This is the same area where you would change the iOS Application Target or the Supported Device Orientations. Under the section 'iPhone/ iPod Deployment Info' clear the 'Main Interface' drop down, leaving it blank. This fixed the issue for me.
Good luck.
The issue is in your nib file. There is an old connection from the LetsEatAppDelegate to the navBar.
I am not sure how your app is set up, there may be an LetsEatAppDelegate object in one of your nib files, or there could be a file owner with the class set to LetsEatAppDelegate
4 Foundation 0x0079f5e5 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 285
5 UIKit 0x0021b30c -[UIRuntimeOutletConnection connect] + 112
6 CoreFoundation 0x00f1a8cf -[NSArray makeObjectsPerformSelector:] + 239
7 UIKit 0x00219d23 -[UINib instantiateWithOwner:options:] + 1041
8 UIKit 0x0021bab7 -[NSBundle(UINSBundleAdditions) loadNibNamed:owner:options:] + 168
2011-11-22 14:39:32.294 LetsEat[15320:b603] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<LetsEatAppDelegate 0x5a824a0> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key navBar.'
*** Call stack at first throw:
Oh man. I was having the same problem after removing #properties and/or IBActions and it was driving me crazy! Warkst was right on the money. Go to the problem view controller, click on the orange ball and deselect any dangling references you find. You may need to scroll down to find them all. This solved my problem. Thanks a million.
Clearing "Main Interface" also solved the issue for me. You may need to perform a "Clean" after clearing "Main Interface" and before building.
I meet this problem too,
1.In AppDelegate method
-(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
the rootViewController is init by this methods initWithNibName..... but actually the nib file is not exist, so the exception throw..
2.When viewController load view it crashes
I guess maybe because I deleted the xib file,then the view controller still init with nib file.. so I add the -(void)load view methods. and it is ok now..ps:I reset the simulator,but it doesn't work.
Hope this help.
I faced the same problem recently. All my outlet connections where perfectly fine though. I finally made it by making decent CLEAN of the project.
Thanks to #Robert Wohnoutka and this post: How to Delete Derived Data and Clean Project in Xcode 5 and Xcode 6?

this class is not key value coding-compliant for the key authView [duplicate]

This question already has answers here:
Xcode - How to fix 'NSUnknownKeyException', reason: … this class is not key value coding-compliant for the key X" error?
(79 answers)
Closed 7 years ago.
When i run my app on simulator it runs well, when i try with device doesn't work and i get these errors:
NOTE: i didn't find any kind of class authView in my code
2011-02-24 12:04:14.472 TestP[473:307] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<TestP 0x19d2b0> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key authView.'
*** Call stack at first throw:
(
0 CoreFoundation 0x33ac0987 __exceptionPreprocess + 114
1 libobjc.A.dylib 0x3347b49d objc_exception_throw + 24
2 CoreFoundation 0x33ac0705 -[NSException dealloc] + 0
3 Foundation 0x3367db4f -[NSObject(NSKeyValueCoding) setValue:forUndefinedKey:] + 182
4 Foundation 0x3367d03b _NSSetUsingKeyValueSetter + 90
5 Foundation 0x3367eda3 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 194
6 Foundation 0x33630b17 -[NSObject(NSKeyValueCoding) setValue:forKeyPath:] + 130
7 UIKit 0x3224c60f -[UIRuntimeOutletConnection connect] + 66
8 CoreFoundation 0x33a63fc7 -[NSObject(NSObject) performSelector:] + 18
9 CoreFoundation 0x33a6cd51 -[NSArray makeObjectsPerformSelector:] + 388
10 UIKit 0x3224b577 -[UINib instantiateWithOwner:options:] + 586
11 UIKit 0x3224cb39 -[NSBundle(UINSBundleAdditions) loadNibNamed:owner:options:] + 92
12 UIKit 0x3209e871 -[UIApplication _loadMainNibFile] + 96
13 UIKit 0x3209a1fd -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 180
14 UIKit 0x3206648b -[UIApplication handleEvent:withNewEvent:] + 1114
15 UIKit 0x32065ec9 -[UIApplication sendEvent:] + 44
16 UIKit 0x32065907 _UIApplicationHandleEvent + 5090
17 GraphicsServices 0x33b0ef03 PurpleEventCallback + 666
18 CoreFoundation 0x33a556ff __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 26
19 CoreFoundation 0x33a556c3 __CFRunLoopDoSource1 + 166
20 CoreFoundation 0x33a47f7d __CFRunLoopRun + 520
21 CoreFoundation 0x33a47c87 CFRunLoopRunSpecific + 230
22 CoreFoundation 0x33a47b8f CFRunLoopRunInMode + 58
23 UIKit 0x32099309 -[UIApplication _run] + 380
24 UIKit 0x32096e93 UIApplicationMain + 670
25 TestP 0x00002213 main + 98
26 TestP 0x000021ac start + 40
)
terminate called after throwing an instance of 'NSException'
You've probably got your File's Owner stuff messed up in your xibs. This exception is getting thrown during nib unarchiving (as evidenced by +[UINib...] in the backtrace). It's attempting to hook up your IBOutlets that you defined.
One of your views is set up to be the authView of the the File's Owner. However, when it's time to unarchive the nib, the owner doesn't have an authView property, so the unarchiving is failing.
#Dave DeLong pointed out right.
Workaround
Find when the exception thrown, which viewController is being loaded.
Then check the nib file of the viewController, there must be an IBOutlet attached in xib but might be missed in the viewController.h file or might be some control which was attached is missing in xib file.
Why running in Simulator? Sometimes it ends in messing up.
Just do the steps
Build -> Clean
Build -> Clean All Targets
Now it runs the real code, may be issue got resolve on device also or may be it start throwing exception on simulator also in case if there is really an issue. (I already have mentioned workaround)
This is how I solved this problem. I went into my 'Story Board' file and selected the view that was causing the problems. I then clicked on the Connections Inspector tab and you will see connection(s) with exclamation points to the right instead of solid circles. Remove these and make adjustments if necessary. Save>Run your app and should work. Hope this helps :)
I think that one possible cause for raising that exception is when you have changed the name of some IBOutlet variable after the storyboard connections are already done. Thus the UI element in the storyboard is still referencing to the old variable name. I solved this for me by checking the XML representation of the storyboard (Right click on your .storyboard file and open it as Source Code) and deleting the old (unneeded) IBOutlet variable name.
For example let say you have one UITextField on the storyboard and have the corresponding property for it:
#property (retain, nonatomic) IBOutlet UItextField *myTextField;
You connect the UI element in the storyboard to that property and then you decide to rename somehow the variable. Now if you right click on your UITextField in the storyboard, you will notice that there exists two referencing outlets - the old one and the new one. You can delete the old one by clicking 'x' sign in the Connections Inspector or by editing the XML variant of the storyboard file.
something went wrong when in xcode 4 with some reference , cause i declared IBOutlet that reference authView then run and it worked!, then i removed the IBOutlet declaration and worked well
I just cleaned the project and deleted the app from the device and it worked again. Error was referencing a view that i had already removed.
You have probably created an IBOutlet, then deleted it, then linked a new one, but in the xib 'Inspector' you forgot to delete the link and now have a duplicate IBOutlet ref that the compiler cannot find.
i have found these errors arise mostly when you connect properties, edit them, and connect them again.. analyse your connection inspector for unexpected values, that remain from your previously created and destroyed connection.
In my case it was even more spooky. I had a XIB associated to the VC that I had removed completely as went for code-only. Run on Simulator nicely but would crash on Device systematically.
So I clean, rebuild, closed XCode, went for a snack and shout at the mac. Nothing, the compiler kept pointing to an inexistent button on an inexistent XIB.
Tried by changing the name of the class and that worked!
It seems that your Interface Builder did not work properly.
As suggested before, try by cleaning and rebuild. If it doesn´t work, I´d suggest you to re-create your xib interface. It worked for me in a similar occasion.

What do the memory addresses in iPhone crash logs signify?

I've been looking at crash logs generated by an iphone app today:
Thread 0 Crashed:
0 libobjc.A.dylib 0x3002d7da 0x3002b000 + 10202
1 UIKit 0x31ec4abc 0x31e4d000 + 490172
2 UIKit 0x31ebd214 0x31e4d000 + 459284
3 UIKit 0x31ebcfac 0x31e4d000 + 458668
Can anyone tell me what the hex addresses mean? (memory addresses, sure..)
I know how to symbolicate to produce:
0 libobjc.A.dylib 0x000027da objc_msgSend + 18
1 UIKit 0x00077abc -[UINavigationController _startDeferredTransitionIfNeeded] + 176
2 UIKit 0x00070214 -[UINavigationController pushViewController:transition:forceImmediate:] + 600
3 UIKit 0x0006ffac -[UINavigationController pushViewController:animated:] + 28
and debug the crash from there, but I'm curious; if you take
0x3002d7da 0x3002b000 + 10202
then: 0x3002d7da = 0x3002b000 + (decimal) 10202
What does this signify exactly?
I should add I'm not looking for info on how to symbolicate, thx!
EDIT: what is also strange to me is that if you compare pre and post symbolicated versions, then for code I wrote:
9 memleaktest 0x00002ffe 0x1000 + 8190
becomes
9 memleaktest 0x00002ffe -[memleaktestViewController buttonOne] (memleaktestViewController.m:24)
makes sense, but for framework code:
8 CoreFoundation 0x307fe52c 0x307f8000 + 25900
becomes
8 CoreFoundation 0x0000652c -[NSObject(NSObject) release] + 24
the address and offset has changed? Why would this be?
if you take
0x3002d7da 0x3002b000 + 10202
What does this signify exactly?
In this case, the "+" doesn't signify addition so much. What this line is telling you is:
The routine/library in question starts at address 0x3002b000
Your line-of-code in the stack trace happened 10202 bytes into it.
The sum of those two numbers = 0x3002d7da
(Put another way, as you did, 0x3002d7da = 0x3002b000 + 10202.)
The important thing about which you might care is the start address of the method being called.
But, really, you can ignore all of that, since it's not nearly as useful as the symbolicated version, which gives you source-file name & line-number.
Extending Olie's response on the "symbolicated version" of the app: The debugging information is stripped from the distribution version of the app to make it smaller and also to protect the developer's intellectual property (so you can't see class and method names).
In order to decrypt the log, you need to have the debugging symbols file associated with the specific build that created the crash log.
This file (.dSYM extension) will be present in the build folder where the binary of the iPhone app is also located. Please note that you need the .dSYM file for the specific compilation that was used to compile the app on the phone - the dSYM file is timestamped, so if you recompile the app, the dSYM file will change even if you don't change a line of code.
Once you have this file on your computer, drag the crash file into xcode (or view logs from attached devices in the Organiser), which will give you a stack trace of the methods called and the specific lines of code called which led to the crash.