Common Crash scenarios and workarounds in iOS

1. Common Crash Scenarios

• A Zombie object was accessed

• Access to non-existent methods

• Array out of bounds

• The timer is released before the timer's next callback and will crash

2. About Bad_access

The reason: Access to the wild pointer, such as access to the object has been disposed of the member variable or send messages, dead loop, etc.;

Workaround:

1. Rewrite the object's Respondstoselector method, first to find the last object accessed before execbadaccess;

2. Set enable Zombie Objects;

3. Set the global breakpoint to quickly locate the problem code in the line, receive all exceptions;

4. The Bad_access capture function has been integrated after Xcode7: Address sanitizer is set as in step 2;

5. Analyze (static analysis, not necessarily useful)

3. When will the unrecognized selector exception be reported?

• When the calling object (subclass, all levels of parent class) does not contain a corresponding method, and there is still no specific scheme for "message forwarding", the program will crash and throw unrecognized selector exception at runtime.

• Each method in the objective-c is converted to a message objc_msgsend (Reciver, selector) at run time

• For example [person say] will be converted to objc_msgsend (person, @selector (say))

• The runtime will find the corresponding class for the object according to the ISA pointer of the object (reciever), then the corresponding method is found in the corresponding class, parent class, Grandpa class, and Root class.

The parsing process for object methods is described below:

• The first step: + (BOOL) Resolveinstancemethod: (SEL) SEL Implementation method, specifies whether the method is added dynamically. If no is returned, the next step is entered, and if yes is returned, the method is dynamically added via the Class_addmethod function, and the message is processed and the process is complete.

• Step two: When the first step returns no, it enters the-(ID) Forwardingtargetforselector: (SEL) Aselector method, which is the second opportunity given to us by the runtime to specify which object responds to this selector. cannot be specified as self. If nil is returned, indicating that there is no responder, the third step is entered. If an object is returned, the method of the object is called.

• Step three: If the second step returns nil, then we first have to pass-(Nsmethodsignature *) Methodsignatureforselector: (SEL) Aselector The specified method signature, if return nil, it means no processing. If a method signature is returned, the next step is entered.

• Fourth step: When the third step returns the method method signature, it calls the-(void) Forwardinvocation: (Nsinvocation *) Aninvocation method, we can do a lot of processing through the Aninvocation object, such as modifying the implementation method, modifying the response object, etc.

• Fifth step: If not implemented-(void) Forwardinvocation: (Nsinvocation *) Aninvocation method, then enter-(void) Doesnotrecognizeselector: (SEL) Aselector method. If we do not implement this method, then we will be crash, and then prompt the method of not hitting the response. By this, the dynamic parsing process is over.

4. How to resolve crash that are difficult to reproduce

1. There is an error log to see the error log information first,

2. There is no error log, the first step is to parse all the branches in the function, whether there is a possible lack of conditions in the syntax of the problem. So check the branches so that each branch executes the correct result.

3. Check the parameters of the function, ensure that the required parameters cannot be NULL, if NULL should throw an exception, so it is important to check the correctness of parameters with assertions

4. Check that functions called by each branch of the function return the result is correct, is actually the recursive process (repeat 2,3 step)

Common Crash scenarios and workarounds in iOS