Debug EXC_BAD_ACCESS follow-up

转自http://www.touch-code-magazine.com/debug-exc_bad_access-follow-up/. 

 

As I described in last months “How to debug EXC_BAD_ACCESS” there are very few reasons for an application to fail with EXC_BAD_ACCESS, but the problem is that this cases sometimes can be very very hard to debug.

For more details see the original article here, while in this article I want to start adding some specific cases, which are a “golden” recipes for getting EXC_BAD_ACCESS.

EXC_BAD_ACCESS in NSLog

Easiest way to get bad access error is to give as an argument a simple type instead of an object, as in the case if you supply an utf8 string instead of NSString to NSLog, like so :

NSLog("This is my object: %@", myObject);

Doesn’t look so bad at first sight, but passing a utf8 string will inevitably product a bad access error.

NB: when you build the project you will get a warning about passing the utf8 string instead of NSString; you can still run the app, but that’s the exact reason you are getting those warnings. While you are working on your app, you SHOULD NOT HAVE ANY warnings.

EXC_BAD_ACCESS while defining a new variable

In a method which has quite some code it’s easy to forget which variables were class members, which were arguments to the method, which are local, etc. Basically this is why all your methods should not be longer that your screen (is the golden rule).

You get EXC_BAD_ACCESS if you try to create a new variable, which has the same name as a method argument.

-(void)saveMySettings:(NSString*)settings

and then later on in the method body if you do :

NSString settings = [NSString stringWithFormat:@"test"];

you will get an EXC_BAD_ACCESS.

Any other such specific cases you would like to share?

Write in the comments or on my email to share more such specific recipes !