IOS-iPhone objective-C exc_bad_access

It is not terrible for iPhone objective-C exc_bad_access to write programs with bugs. For most problems, it is not difficult to find the cause through simple log or code analysis. However, when the problem of exc_bad_access is encountered in objective-C programming, it is difficult to find the problem through simple and conventional means.

It is not terrible to encounter bugs when writing programs. Most of the problems are difficult to find the cause through simple log or code analysis. However, when the problem of exc_bad_access is encountered in objective-C programming, it is difficult to find the problem through simple and conventional means. This article describes a common method for finding the root cause of the exc_bad_access problem.

First, let's talk about the exc_bad_access error. It can be said that the 90% error is caused by the release operation on a released object.

The objective-C code has three fatal problems: 1. Memory leakage; 2. Release of errors; 3. exc_bad_access error.

1, nsstring * s = [[nsstring alloc] initwithstring: @ "this is a test string"]; creates an nsstring object, and then S = [s substringfromindex: [s rangeofstring: @ "A"]. location]; after execution, the created object reference disappears, directly causing memory leakage.

2. Release error. [S release]; one of the reasons for this problem is a logic error, thinking that S is the nsstring object we initially created. The second reason is that the nsstring object returned from the substringfromindex :( nsuinteger I) method does not need to be released. It is actually an object marked as autorelease BY THE substringfromindex method. If we forcibly release it, it will cause exc_bad_access problems.

3, exc_bad_access. Because the nsstring object to which s points is marked as autorelease, there is a record in the ntutoreleasepool. However, because we released this object in the previous error, when [pool drain], the NSAID utoreleasepool again called the release method for the s Object recorded by it, but at this time s has been released and no longer exists, it directly causes the exc_bad_access problem.

View More console Information

Workspace-> excuteables-> double-click a file under its group-> arguments to set running parameters

1: add the nszombieenabled environment variable to the project runtime. When exc_bad_access occurs, the xcode console prints the Problem description.

2: Add mallocstacklogging to enable malloc records

Make the following settings:

Project-> edit active executable-> argument

Add the following four parameters:

Nsdebugenabled

Nszombieenabled

Mallocstacklogging

Mallocstackloggingnocompact

It is not terrible for iPhone objective-C exc_bad_access to write programs with bugs. For most problems, it is not difficult to find the cause through simple log or code analysis. However, when the problem of exc_bad_access is encountered in objective-C programming, it is difficult to find the problem through simple and conventional means.

It is not terrible to encounter bugs when writing programs. Most of the problems are difficult to find the cause through simple log or code analysis. However, when the problem of exc_bad_access is encountered in objective-C programming, it is difficult to find the problem through simple and conventional means. This article describes a common method for finding the root cause of the exc_bad_access problem.

First, let's talk about the exc_bad_access error. It can be said that the 90% error is caused by the release operation on a released object.

The objective-C code has three fatal problems: 1. Memory leakage; 2. Release of errors; 3. exc_bad_access error.

1, nsstring * s = [[nsstring alloc] initwithstring: @ "this is a test string"]; creates an nsstring object, and then S = [s substringfromindex: [s rangeofstring: @ "A"]. location]; after execution, the created object reference disappears, directly causing memory leakage.

2. Release error. [S release]; one of the reasons for this problem is a logic error, thinking that S is the nsstring object we initially created. The second reason is that the nsstring object returned from the substringfromindex :( nsuinteger I) method does not need to be released. It is actually an object marked as autorelease BY THE substringfromindex method. If we forcibly release it, it will cause exc_bad_access problems.

3, exc_bad_access. Because the nsstring object to which s points is marked as autorelease, there is a record in the ntutoreleasepool. However, because we released this object in the previous error, when [pool drain], the NSAID utoreleasepool again called the release method for the s Object recorded by it, but at this time s has been released and no longer exists, it directly causes the exc_bad_access problem.

View More console Information

Workspace-> excuteables-> double-click a file under its group-> arguments to set running parameters

1: add the nszombieenabled environment variable to the project runtime. When exc_bad_access occurs, the xcode console prints the Problem description.

2: Add mallocstacklogging to enable malloc records

Make the following settings:

Project-> edit active executable-> argument

Add the following four parameters:

Nsdebugenabled

Nszombieenabled

Mallocstacklogging

Mallocstackloggingnocompact