Home  >  Article  >  Database  >  iOS内存错误EXC_BAD_ACCESS的解决方法

iOS内存错误EXC_BAD_ACCESS的解决方法

WBOY
WBOYOriginal
2016-06-07 15:36:301150browse

iOS开发,最郁闷的莫过于程序毫无征兆地就崩溃了,用bt命令打出调用栈,给出的是一堆系统EXC_BAD_ACCESS的信息,根本没办法定位问题出现在哪里。 首先说一下 EXC_BAD_ACCESS 这个 错误 ,可以这么说,90%的 错误 来源在于对一个已经释放的对象进行release操

iOS开发,最郁闷的莫过于程序毫无征兆地就崩溃了,用bt命令打出调用栈,给出的是一堆系统EXC_BAD_ACCESS的信息,根本没办法定位问题出现在哪里。 首先说一下 EXC_BAD_ACCESS 这个错误,可以这么说,90%的错误来源在于对一个已经释放的对象进行release操作。举一个简单的例子来说明吧,首先看一段Java代码:

复制代码 代码如下:


public class Test{
public static void main(String[] args){
String s = "This is a test string";
s = s.substring(s.indexOf("a"),(s.length()));
System.out.println(s);

}
}



通常这样的崩溃出现,原因一般就是:调用了已经释放的内存空间,或者说重复释放了某个地址空间。而怎样定位到这个地址呢,可以通过编辑xcode的scheme,添加如下标记位,让系统把错误地址打印出来,如图:

(通过Product->Scheme->Edit Scheme进入下面编辑页面,选中Arguments tab,增加标计位NSZombieEnabled设为YES)

这样,但崩溃出现,系统会出现以下提示信息:

2013-06-23 00:45:20.479 *** -[__NSArrayM addObject:]: message sent to deallocated instance 0x7179910

可见崩溃原因是内存地址0x7179910被重复释放了。

Objective-C 这段代码有三个致命问题:1、内存泄露;2、错误释放;3、造成 EXC_BAD_ACCESS 错误

如果崩溃是发生在当前调用栈,通过上面的做法,系统就会把崩溃原因定位到具体代码中。但是,如果崩溃不在当前调用栈,系统就仅仅只能把崩溃地址告诉我们,而没办法定位到具体代码,这样我们也没法去修改错误。这时就可以修改scheme,让xcode记录每个地址alloc的历史,这样我们就可以用命令把这个地址还原出来。如图:(跟设置NSZombieEnabled一样,添加MallocStackLoggingNoCompact,并且设置为YES)

这样,当出现崩溃原因是message sent to deallocated instance 0x7179910,我们可以使用以下命令,把内存地址还原:

info malloc-history 0x7179910

如图,这个命令能具体把这个地址在哪一行代码生成还原出来。

(需要注意的是,因为这个命令只支持gdb,所以必须把控制台的输出改成gdb,并且有点遗憾的是,只支持模拟器,不支持真机调试)

(同样是通过Product->Scheme->Edit Scheme进入上面编辑页面,选中Info tab)

这样,好好检查一下那一行的代码,应该就很容易找出问题所在了。

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn