At some point, you may encounter a crash caused by exc_bad_access. In this article, you will learn what is exc_bad_access and what it is caused by. I will also present some tips for solving bugs caused by exc_bad_access. what is exc_bad_access.
Once you understand the root cause of exc_bad_access, you will better understand its ambiguous name. Here's a simple explanation and a more professional explanation. Let's start with this simple explanation. Keep it simple
Whenever you encounter a exc_bad_access, that means you are sending a message to an object that has been released. This is the most common scenario, but here's a look at more explanations. true Meaning
Professional explanations are somewhat complicated. In C and objective-c, pointers are often processed. The pointer is nothing more than a variable that stores the memory address of another variable. When you send a message to an object, the pointer to the object needs to be referenced. This means that you get the memory address that the pointer points to and access the value of that chunk of memory.
When that memory is no longer mapped to your application, or, in other words, that memory is no longer being used in the way you expect, then you may not be able to access that chunk of memory. When this happens, the kernel sends an exception ( exc ), indicating that your application has no access to that block of memory (badaccess).
To sum up: when you encounter exc_bad_access, it means that you are trying to send a message to a piece of memory that is not able to execute the message.
Sometimes, however, exc_bad_access is caused by a corrupt pointer (that is, a wild pointer). Every time your application tries to refer to a corrupt pointer pointer, the kernel throws an exception.
Note: Corrupt pointer: Can be understood as "wild pointer". Refers to a pointer to a deleted object or to an application that does not request access to the restricted memory area. Unlike a null pointer, a wild pointer cannot be avoided simply by determining whether it is null, but by developing good programming habits to minimize it. Manipulating wild pointers can easily result in program errors. Debug Exc_bad_access
Debugging exc_bad_access can be tricky and frustrating. Show that now exc_bad_access is no longer such a difficult thing for you.
The first thing you need to know is that once a block of memory is inaccessible, your application crashes. This is why debugging is so difficult exc_bad_access.
Similarly, when you reference a wild pointer, the situation is bad. Zombies
Although zombies have been popularized in the past few years, they have been in Xcode for more than 10 years. The name "zombie" may sound dramatic, but it's a great name for explaining how we debug exc_bad_access.
In Xcode, you can enable zombie objects (Zombie objects), which means that the released objects are kept as "zombies". In other words, the freed object is kept active in order to debug the program. It doesn't have any magical effect. If you send a message to a zombie object, your application will still get a exc_bad_access crash.
Why it is useful to enable zombie. The reason for making exc_bad_access difficult to debug is that you don't know what your application is trying to access. In a variety of situations, zombie objects can solve this problem. By keeping the freed object active, Xcode can tell you the object the application is trying to access and make it easier to retrieve the problem.
Enabling Zombies in Xcode is simple. Note that your Xcode version may lead to different methods. The following methods apply to Xcode 6 and Xcode 7. Select the product-> selection scheme in the toolbar-> choose Edit Scheme. Or use the shortcut command+<.
Select Run on the left, open the Diagnotics (diagnostics) in the Top tab, and check the checkbox to enable Zombie Objects.
If you now encounter the output of the Exc_bad_access,xcode console it will give you a better idea of where to start retrieving errors. Take a look at the following example:
2015-08-12 06:31:55.501 debug[2371:1379247]-[childviewcontroller respondstoselector:] message sent to deallocated Instance 0x17579780
In the above example, Xcode is telling us that this message is Respondstoselector: Sent to a Zombie object. However, the zombie object is no longer an instance object of the Childviewcontroller class. The memory blocks that were previously assigned to the Childviewcontroller instance object are no longer mapped to your application. It helps you understand the root cause of the problem.
Unfortunately, zombies do not solve any of the crashes you encounter caused by exc_bad_access. If the Zombie object doesn't solve your problem, then try to do some analysis. Analysis
The root cause is important if the zombie object doesn't help you. In this case, you should take a closer look at the code that is executing when your application crashes. This process can be time-consuming and cumbersome.
To help you find the problem in your code, you can let Xcode analyze your code to help you find the problem interval. Note that Xcode analysis of your project may indicate any potential problems it encounters.
Select Product->analyze, or shortcut shift+command+b, to enable Xcode's analysis of your project.
This can take xcode a few minutes, but when it's done, you'll see a list of issues in the problem navigator on the left. Problems identified by the analysis are highlighted in blue.
When you click on a question, Xcode locates the piece of code that needs your attention. It should be noted that Xcode is only making recommendations, and at some point, it is possible that the problem is irrelevant or that you do not need to solve it.
If you can't find bugs that cause exc_bad_access, it's important to double-check the problems that Xcode found during the analysis. Conclusions
Exc_bad_access is a common setback for developers, something that is unique to manual memory management. Memory management related issues have been less frequent since the launch of Arc, but they have not disappeared.
This article is translated from: http://code.tutsplus.com/tutorials/what-is-exc_bad_access-and-how-to-debug-it–cms-24544