The essence of exc_bad_access and the principle of zombie mode debugging

Sometimes, you will encounter a crash caused by exc_bad_access. This article will tell you what is exc_bad_access and why it is produced. I will also provide some solutions for exc_bad_access errors.

1. What is exc_bad_access?

Once you understand the nature of exc_bad_access, you will be better able to understand this vague noun. Here is a very simple explanation, and there is a technical explanation. Let's start with a simple explanation.

2. A simple explanation

Whenever you encounter exc_bad_access this error, it means that you send a message to an already released object. This is the most common case, but there are exceptions, which we will discuss later.

3. The nature of exc_bad_access

The technical explanation is somewhat complex. In C and Objective-c, you've been working with pointers. The pointer is nothing more than a variable that stores the memory address of another variable. When you send a message to an object, a pointer to that object is referenced. This means that you get the memory address that the pointer refers to and access the value of that storage area.

When the memory area is no longer mapped to your app, or in other words, the memory area is not used when you think it is used, and the memory area is inaccessible. At this point the kernel throws an exception (EXC), indicating that your application cannot access the memory area (bad access).

In short, when you touch exc_bad_access, this means that you are trying to send a message to the memory block, but the memory block cannot execute the message. However, in some cases, the exc_bad_access is caused by a damaged pointer. Whenever your application tries to reference a corrupted pointer, an exception is thrown by the kernel.

4. Debug Exc_bad_access

Debugging exc_bad_access can be tricky and frustrating. However, now exc_bad_access is no longer a mystery, it is not as scary as it is imagined.

The first thing you need to know is that your application is not necessarily at the moment of the crash and cannot access the memory area. This is why it is often difficult to debug exc_bad_access.

The same is true for damaged pointers. When your pointer is damaged, your application does not crash. Also, if you pass a damaged pointer back and forth in the application, it does not crash. A crash occurs when an application attempts to reference a damaged pointer.

5. Zombie Debug Mode

The zombie debug mode has gained popularity over the last few years, and in fact they have been on Xcode for more than 10 years. Zombies sound a little dramatic, but it's actually a great name to help us debug the exc_bad_access feature. Let me explain how it works.

In Xcode, you can enable zombie objects, which means that objects that are freed will be kept in the form of zombies. In other words, the object being disposed is for debugging. There is no magic involved here. If you send a message to a zombie object, your application will crash due to exc_bad_access.

What good is that? The reason why exc_bad_access is difficult to debug is that you don't know which object your application is trying to access. Zombie objects solve this problem in many cases. By keeping objects that have been disposed of, Xcode can tell you which object you are trying to access, which makes it much easier to find the cause of the problem.

It's easy to enable zombie objects in Xcode. Note that this may vary depending on the version of Xcode. The following methods apply to Xcode 6 and 7, click Edit Scheme in the upper-left corner, and select Edit Scheme.

Select Run on the left and open the diagnostics option above. To enable the Zombie object, tick the Enable Zombie objects marquee.

If you now encounter exc_bad_access, in the Xcode console output, tell you where to look for the problem. Take a look at the example output below.

2015-08-12 06:31:55.501 debug[2371:1379247]-[childviewcontroller respondstoselector:] message sent to deallocated Instance 0x17579780

In the example above, Xcode tells us that Respondstoselector message: is sent to a zombie object. However, the zombie object is no longer an instance of the Childviewcontroller class. The area of memory previously assigned to the Childviewcontroller instance is no longer mapped to your application. This provides a good idea for you to understand the root cause of the problem.

Unfortunately, zombie objects will not be able to save your exc_bad_access record for every crash of your day. Since zombie objects do not have these methods, you can take other methods to do some proper analysis.

6. Analysis

If a zombie object doesn't solve your problem, the root cause of the problem may not be that simple. In this case, you need to take a closer look at the code that executes when the application crashes. This can be tedious and time-consuming.

To help you find the problem with your code, you can use Xcode to analyze your code to help you find where the problem occurs. Note that Xcode analyzes the project and it will indicate where each potential problem may arise.

Using Xcode to analyze your project, selecting Analyze from the Xcode product menu or pressing Shift-command-b.xcode will take a moment, but when it is done you will see the list of issues on the left Issue navigator. Problems discovered by analyze are highlighted in blue.

When you click on a question, Xcode will point to the problem code block, which is exactly where you want to be noticed. Note that Xcode is just a suggestion. In some cases, it is possible that the problem is irrelevant and not fixed.

If you can't find the error that caused exc_bad_access, you need to look at the Xcode project and analyze every problem you find.

7. Conclusion

Exc_bad_access is a common problem that developers face, which is inherent in manual memory management. Although the implementation of the ARC memory management (automatic reference counting) makes exc_bad_access less frequent, but they do not really disappear.

The essence of exc_bad_access and the principle of zombie mode debugging