接收到EXC_BAD_ACCESS信号 [英] EXC_BAD_ACCESS signal received

查看:127
本文介绍了接收到EXC_BAD_ACCESS信号的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

将应用程序部署到设备时,程序会在几个周期后退出,并显示以下错误:

When deploying the application to the device, the program will quit after a few cycles with the following error:

Program received signal: "EXC_BAD_ACCESS".

程序在iPhone模拟器上运行没有任何问题,它也将调试和运行,逐步通过指令一个。一旦我让它再次运行,我将击中 EXC_BAD_ACCESS 信号。

The program runs without any issue on the iPhone simulator, it will also debug and run as long as I step through the instructions one at a time. As soon as I let it run again, I will hit the EXC_BAD_ACCESS signal.

在这种特殊情况下,恰好是加速度计代码中的错误。它不会在模拟器内执行,这就是为什么它不会抛出任何错误。

In this particular case, it happened to be an error in the accelerometer code. It would not execute within the simulator, which is why it did not throw any errors. However, it would execute once deployed to the device.

此问题的大部分答案处理一般 EXC_BAD_ACCESS

Most of the answers to this question deal with the general EXC_BAD_ACCESS error, so I will leave this open as a catch-all for the dreaded Bad Access error.

EXC_BAD_ACCESS 错误,因此我将此打开作为一个全面的可怕的错误访问错误。通常作为非法存储器访问的结果而被抛出。您可以在下面的答案中找到更多信息。

EXC_BAD_ACCESS is typically thrown as the result of an illegal memory access. You can find more information in the answers below.

您之前遇到过 EXC_BAD_ACCESS 处理它?<​​/ p>

Have you encountered the EXC_BAD_ACCESS signal before, and how did you deal with it?

推荐答案

从你的描述我怀疑最可能的解释是你的内存管理有一些错误。你说你一直在开发iPhone几个星期,但不是你是否有Objective C的经验。如果你来自另一个背景,你可能需要一段时间才能真正内化内存管理规则 - 除非你有一个大点。

From your description I suspect the most likely explanation is that you have some error in your memory management. You said you've been working on iPhone development for a few weeks, but not whether you are experienced with Objective C in general. If you've come from another background it can take a little while before you really internalise the memory management rules - unless you make a big point of it.

记住,任何东西你从一个分配函数(通常是静态alloc方法,但有一些其他),或一个复制方法,你拥有内存,并必须释放它,当你完成后。

Remember, anything you get from an allocation function (usually the static alloc method, but there are a few others), or a copy method, you own the memory too and must release it when you are done.

但是,如果你从包含工厂方法(例如 [NSString stringWithFormat] )有一个自动释放引用,这意味着它可以在将来的某个时间被其他代码释放 - 所以如果你需要保持它超出你保留它的直接函数是至关重要的。如果不这样做,在使用它时,内存可能会保持分配,或者在仿真器测试期间仍然有效,但更可能被释放,并在设备上运行时显示为错误的访问错误。

But if you get something back from just about anything else including factory methods (e.g. [NSString stringWithFormat]) then you'll have an autorelease reference, which means it could be released at some time in the future by other code - so it is vital that if you need to keep it around beyond the immediate function that you retain it. If you don't, the memory may remain allocated while you are using it, or be released but coincidentally still valid, during your emulator testing, but is more likely to be released and show up as bad access errors when running on the device.

追踪这些事情的最佳方法是一个好主意(即使没有明显的问题)是在Instruments工具中运行应用程序,特别是Leaks选项。

The best way to track these things down, and a good idea anyway (even if there are no apparent problems) is to run the app in the Instruments tool, especially with the Leaks option.

这篇关于接收到EXC_BAD_ACCESS信号的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆