xcode crash 查找 EXC_BAD_ACCESS 有关问题根源的方法

最新推荐文章于 2022-03-14 15:02:37 发布

xiacsd

最新推荐文章于 2022-03-14 15:02:37 发布

阅读量1k

点赞数

分类专栏： iOS

iOS 专栏收录该内容

21 篇文章 0 订阅

订阅专栏

转载：xcode crash 查找 EXC_BAD_ACCESS 有关问题根源的方法

xcode crash 查找 EXC_BAD_ACCESS 问题根源的方法

xcode5 5.x

EXC_BAD_ACCESS这个问题一直不好调试，之前有看到过说配置一个环境变量可以很方便的跟踪问题，因此试了一下，发现还真是方便了很多，以下是XCODE 4的配置方法：

Edit Scheme->Arguments->Environment variables

增加 NSZombieEnabled ，设置为YES，并勾选上，OK，再次运行，在console就会显示出出错的地方了.

(另外：

NSLog(@"id : %@",id); //id is integer,should be printed as %d

像这样的语句也会引起EXC_BAD_ACCESS，大家要注意了哦

)

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
        NSString* s = [[NSString alloc]initWithString:@”This is a test string”];
        s = [s substringFromIndex:[s rangeOfString:@"a"].location];//内存泄露
        [s release];//错误释放
[pool drain];//EXC_BAD_ACCESS
return 0;
}

    这个例子当然狠容易的看出问题所在，如果这段代码包含在一个很大的逻辑中，确实容易被忽略。Objective-C 这段代码有三个致命问题：1、内存泄露；2、错误释放；3、造成 EXC_BAD_ACCESS 错误。

1， NSString* s = [[NSString alloc]initWithString:@”This is a test string”]; 创建了一个 NSString Object，随后的 s = [s substringFromIndex:[s rangeOfString:@"a"].location]; 执行后，导致创建的对象引用消失，直接造成内存泄露。

2，错误释放。[s release]; 这个问题，原因之一是一个逻辑错误，以为 s 还是我们最初创建的那个 NSString 对象。第二是因为从 substringFromIndex:(NSUInteger i) 这个方法返回的 NSString 对象，并不需要我们来释放，它其实是一个被 substringFromIndex 方法标记为 autorelease 的对象。如果我们强行的释放了它，那么会造成 EXC_BAD_ACCESS 问题。

3， EXC_BAD_ACCESS。由于 s 指向的 NSString 对象被标记为 autorelease, 则在 NSAutoreleasePool 中已有记录。但是由于我们在前面错误的释放了该对象，则当 [pool drain] 的时候，NSAutoreleasePool 又一次的对它记录的 s 对象调用了 release 方法，但这个时候 s 已经被释放不复存在，则直接导致了 EXC_BAD_ACCESS问题。

那么，知道了 EXC_BAD_ACCESS 的诱因之一后，如何快速高效的定位问题？

1: 为工程运行时加入 NSZombieEnabled 环境变量，并设为启用，则在 EXC_BAD_ACCESS 发生时，XCode 的 Console 会打印出问题描述。

首先双击 XCode 工程中，Executables 下的可执行模组，

在弹出窗口中，Variables to be set in the environment，添加 NSZombieEnabled，并设定为 YES，点击选中复选框启用此变量。

这样，运行上述 Objective-C 时会看到控制台输出：Untitled[3646:a0f] *** -[CFString release]: message sent to deallocated instance 0x10010d340

这条消息对于定位问题有很好的提示作用。但是很多时候，只有这条提示是不够的，我们需要更多的提示来帮助定位问题，这时候再加入 MallocStackLogging 来启用malloc记录。

当错误发生后，在终端执行：

malloc_history ${App_PID} ${Object_instance_addr}

则会获得相应的 malloc 历史记录，比如对于上一个控制台输出

Untitled[3646:a0f] *** -[CFString release]: message sent to deallocated instance 0x10010d340

则我们可以在终端执行，结果如下：

这样就可以很快的定位出问题的代码片段了，注意输出的最后一行，，，这行虽然不是问题的最终原因，但是离问题点已经很近了，随着它找下去，八成就会找到问题。

EXC_BAD_ACCESS(code=2,address=0xcc 异常解决及建议不要在子线程中刷新界面

iOS 上不建议在非主线程进行UI操作，在非主线程进行UI操作有很大几率会导致程序崩溃，或者出现预期之外的效果。

我开始不知道这一点，在子线程中进行了弹窗操作，结果程序就出问题了！

报的错误是（EXC_BAD_ACCESS(code=2,address=0xcc)，0x1a0ad32: movl 204(%ecx), %edx ），我以为是空指针导致的内存泄露，用了很多方法，但这问题感觉很顽固，困扰了我很多天。

后来有位大牛指点了我，问我是不是在子线程进行这个弹窗操作。。。直到此时我才明白问题出在哪里，问题顺利解决。有时候出现bug却不知道是哪引起的，这时是最纠结的，等明确了问题所在，问题就不是问题了。好了，言归正传。

那么在子线程中的UI操作如何处理呢？有两种方法：

一：在子线程，你需要进行的UI操作前添加dispatch_async函数，即可将代码块中的工作转回到主线程

 dispatch_async(dispatch_get_main_queue(), ^{  
            //更新UI操作  
            //.....  
        });

dispatch_async函数是异步操作，对于比较耗时的操作也可以这样处理：

dispatch_async(dispatch_get_global_queue(0, 0), ^{  
    // 处理耗时操作的代码块...  
      
    //通知主线程刷新  
    dispatch_async(dispatch_get_main_queue(), ^{  
        //回调或者说是通知主线程刷新，  
    });  
      
});

dispatch_async开启一个异步操作，第一个参数是指定一个gcd队列，第二个参数是分配一个处理事物的程序块到该队列。

dispatch_get_global_queue(0, 0)，指用了全局队列。

一般来说系统本身会有3个队列。

global_queue，current_queue,以及main_queue.

获取一个全局队列是接受两个参数，第一个是我分配的事物处理程序块队列优先级。分高低和默认，0为默认2为高，-2为低

二：performSelectorOnMainThread

performSelectorOnMainThread是指在主线程上执行某个方法，比如数据下载后，更新UI界面等操作

例如：在子线程中使用[self performSelectorOnMainThread:@selector(endThread) withObject:nil waitUntilDone:NO];

-(void)setupThread:(NSArray*)userInfor{  
  
   [NSThread detachNewThreadSelector:@selector(threadFunc:) toTarget:self withObject:(id)userInfor];  
  
}  
  
- (void)threadFunc:(id)userInfor{  
  
   NSAutoreleasePool*pool = [[NSAutoreleasePool alloc] init];  
  
   //。。。。需要做的处理。  
  
   //这里线程结束后立即返回  
  
  [self performSelectorOnMainThread:@selector(endThread) withObject:nil waitUntilDone:NO];  
  
  [pool release];  
  
}

performSelectorOnMainThread通知主线程执行函数endThread。

再次强调子线程内不要进行任何UI操作，不要刷新界面。如果需要进行这些操作，通过dispatch_async或performSelectorOnMainThread这两种方法，调出主线程中的方法去执行。

iOS关于error can't allocate region的一点发现

http://www.cocoachina.com/bbs/read.php?tid=135498

技术问题发到问答：我知道，我仍旧要在论坛继续发布问题

最近在搞ios的项目，调试的时候出现 error can't allocate region错误，后来去搜了下网上关于这个错误的帖子，是这么说的：

error can't allocate region 程序运行报错，在xcode中则会发出“SIGABRT”信号来终止程序。
原因是程序运行内存不足，欲申请空间得不到分配。
此时可以查找程序是否出现程序一直申请内存，出现死循环.
SIGABRT 程序自己发现错误并调用abort来终止程序.
可能是程序没有内存可分配导致,运行终止.
但是！
问题还是存在，无论我怎么改，leaks检测到内存没有泄漏和增长的情况，但程序的内存空间一直在减少直到出现这个问题，百思不得其解，到底是什么导致
这种情况出现的呢？？！！！后来我终于发现了，我的在程序中开了NSZombieEnabled这几个跟踪内存错误信息了，就是下图