XCode的一些调试技巧搜集

XCode 内置GDB，咱们能够在命令行中使用 GDB 命令来调试咱们的程序。下面将介绍一些经常使用的命令以及调试技巧。

po 命令：为 print object 的缩写，显示对象的文本描述（显示从对象的 description 消息得到的字符串信息）。

好比：

上图中，我使用 po 命令显示一个 NSDictionary 的内容。注意在左侧咱们能够看到 dict 的一些信息：3 key/value pairs，显示该 dict 包含的数据量，而展开的信息显示 isa 层次体系（即class 和 metaclass结构关系）。咱们能够右击左侧的 dict，选中“Print Description of "dict"”，则能够在控制台输出 dict 的详细信息：

[cpp] view plaincopyprint?

Printing description of dict:  

<CFBasicHash 0x1001149e0 [0x7fff7e27ff40]>{type = immutable dict, count = 3,  

entries =>  

    0 : <CFString 0x100002458 [0x7fff7e27ff40]>{contents = "first"} = <CFString 0x100002438 [0x7fff7e27ff40]>{contents = "one"}  

    1 : <CFString 0x100002498 [0x7fff7e27ff40]>{contents = "second"} = <CFString 0x100002478 [0x7fff7e27ff40]>{contents = "two"}  

    2 : <CFString 0x1000024d8 [0x7fff7e27ff40]>{contents = "third"} = <CFString 0x1000024b8 [0x7fff7e27ff40]>{contents = "three"}  

}  

(gdb)   

print 命令：有点相似于格式化输出，能够输出对象的不一样信息：

如：

[cpp] view plaincopyprint?

(gdb) print (char *)[[dict description] cStringUsingEncoding:4]  

$1 = 0x1001159c0 "{\n    first = one;\n    second = two;\n    third = three;\n}"  

(gdb) print (int)[dict retainCount]  

$2 = 1  

(gdb)   

注：4是 NSUTF8StringEncoding 的值。

 

info 命令：咱们能够查看内存地址所在信息

好比 "info symbol 内存地址" 能够获取内存地址所在的 symbol 相关信息：

[cpp] view plaincopyprint?

(gdb) info symbol 0x00000001000017f7  

main + 343 in section LC_SEGMENT.__TEXT.__text of /Users/LuoZhaohui/Library/Developer/Xcode/DerivedData/RunTimeSystem-anzdlhiwvlbizpfureuvenvmatnp/Build/Products/Debug/RunTimeSystem  

好比 "info line *内存地址" 能够获取内存地址所在的代码行相关信息：

[cpp] view plaincopyprint?

(gdb) info line *0x00000001000017f7  

Line 62 of "/Users/LuoZhaohui/Documents/Study/RunTimeSystem/RunTimeSystem/main.m" starts at address 0x1000017f7 <main+343> and ends at 0x10000180a <main+362>.  

show 命令：显示 GDB 相关的信息。如：show version 显示GDB版本信息

[cpp] view plaincopyprint?

(gdb) show version  

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)  

Copyright 2004 Free Software Foundation, Inc.  

GDB is free software, covered by the GNU General Public License, and you are  

welcome to change it and/or distribute copies of it under certain conditions.  

Type "show copying" to see the conditions.  

There is absolutely no warranty for GDB.  Type "show warranty" for details.  

This GDB was configured as "x86_64-apple-darwin".  

 

help 命令：若是忘记某条命令的语法了，可使用 help 命令名 来获取帮助信息。如：help info 显示 info 命令的用法。

[cpp] view plaincopyprint?

(gdb) help info  

Generic command for showing things about the program being debugged.  

List of info subcommands:  

info address -- Describe where symbol SYM is stored  

info all-registers -- List of all registers and their contents  

info args -- Argument variables of current stack frame  

info auxv -- Display the inferior's auxiliary vector  

info breakpoints -- Status of user-settable breakpoints  

info catch -- Exceptions that can be caught in the current stack frame  

info checkpoints -- Help  

info classes -- All Objective-C classes  

......  

Type "help info" followed by info subcommand name for full documentation.  

Command name abbreviations are allowed if unambiguous.  

(gdb)   

在系统抛出异常处设置断点

有时候咱们的程序不知道跑到哪一个地方就 crash 了，而 crash 又很难重现。保守的作法是在系统抛出异常以前设置断点，具体来讲是在 objc_exception_throw处设置断点。设置步骤为：首先在 XCode 按 CMD + 6，进入断点管理窗口；而后点击右下方的 +，增长新的 Symbolic Breakpoint，在 Symbol 一栏输入：objc_exception_throw，而后点击 done，完成。 这样在 Debug 模式下，若是程序即将抛出异常，就能在抛出异常处中断了。好比在前面的代码中，我让 [firstObjctcrashTest]; 抛出异常。在 objc_exception_throw 处设置断点以后，程序就能在该代码处中断了，咱们从而知道代码在什么地方出问题了。

 

命 令                        解释
break NUM               在指定的行上设置断点。
bt                      显 示全部的调用栈帧。该命令可用来显示函数的调用顺序。
clear                   删 除设置在特定源文件、特定行上的断点。其用法为：clear FILENAME:NUM。
continue                继续执行正在调试的程序。该命令用在程序 因为处理信号或断点而
                        致使中止运行 时。
display EXPR            每次程序中止后显示表达式的值。表达式由程序定 义的变量组成。
file FILE               装载指定的可执行文件进行调试。
help NAME               显 示指定命令的帮助信息。
info break              显 示当前断点清单，包括到达断点处的次数等。
info files              显 示被调试文件的详细信息。
info func               显示全部的函数名称。
info local              显 示当函数中的局部变量信息。
info prog               显示被调试程序的执行状 态。
info var                显示全部的全局和静态变量名称。
kill                    终 止正被调试的程序。
list                    显示源代码段。
make                    在 不退出 gdb 的状况下运行 make 工具。
next                    在 不单步执行进入其余函数的状况下，向前执行一行源代码。
print EXPR              显 示表达式 EXPR 的值。

print- object            打印一个对象
print (int) name      打印一个类型
print- object [artist description]   调用一个函数
set artist = @"test"    设置变量值
whatis                      查 看变理的数据类型

 

 

 

Crash的问题。Crash最多的无非就两种，一种就是signal SIGABRT,大概的意思就是发送Message出现问题，信号迷失了。这种的Crash实际上是很好定位，Crash了后直接看Console里出的最后日志，好比这段：

 

2012-03-28 19:26:33.055 TableViewMenuDemo[3916:f803] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[__NSArrayI replaceObjectAtIndex:withObject:]: unrecognized selector sent to instance 0x6a3f3d0′

 

*** First throw call stack:

 

找到reason字段，那就是缘由,说NSArray 调用replaceObjectAtIndex:withObject：

 

这个方法是NSMutableArry的，NSArray并无该方法。信号迷失掉了，因此Crash了。0x6a3f3d0 是出问题的内存地址,查下内存地址或搜下调用方法就比较好定位了。

 

 

Xcode4上还有个更好用的定位方法，就是设置一个Exception Breakpoint就行了。

 

看图在工程的左边栏中选择Breakpoint Navigator,点击下面的+号添加一个Exception Breakpoint，而后再运行试试，Crash后，是否是直接定位到了那行代码了？再根据Console里的日志进行定位修改就行了。

 

下面说说另外一种Crash, EXC_BAD_ACCESS,这个比较头疼，由于Crash的时候，多是比较早以前的某个变量释放了，如今访问时出问题。Console里也没显示什么日志。

 

这里光加入Exception Breakpoint是不够的了，XCode4还个可爱的地方，打开Scheme选项选择EditScheme。

 

 

 

而后按图勾上Enable Zombie Objects和Malloc Stack那两项，记住通常只有在定位EXC_BAD_ACCESS时候才勾选，别有事没事都勾上。

 

这样从新跑一下，若是是到Exception Breakpoint处中止了，能够在Console中输入：c（continue)按回车继续跑，直到Crash。看下Console是否是有跟SIGABRT相似的错误信息日志了，后面定位什么的你懂的。

 

若是尚未日志，在Console中输入po$eax$eax标志出错的地方，适用模拟器，真机用$r0（话说EXC_BAD_ACCESS这种错误模拟器定位就行）,还能够输入好比：po[$eaxname]po[$eaxreason]等指令查看错误其余信息（注意方括号后没分号的）。而后，就没有而后了。

 

还要补充点，程序开发过程就要多关注左边栏中Issue Navigator里的警告信息，Xcode4不只会警告，还多数给出解决建议，能避免后面没必要要的Crash。

 

 

若是程序Crash，第一时间关注下debug Navigator里的执行信息，将滑块拉向右边能够看到更多调用信息，根据这个能大体设想是调用什么方法或进行什么操做时Crash的。

 

 

 

一、使用僵尸变量(NSZombieEnabled)

 二、重写object的respondsToSelector方法

在iphone开发的时候EXC_BAD_ACCESS这个bug时不容易找到缘由的。

首先说一下EXC_BAD_ACCESS 这个错误，能够这么说，90%的错误来源在于对一个已经释放的对象进行release操做,或者操做一个在循环代码中被修改的序列中的对象。虽然使用NSZombieEnabled变量能够帮助你找到问题所在，但有的时候，即便经过设置NSZombieEnabled变量，仍是不能定位到问题所在，这个时候，你能够试试重写object的respondsToSelector方法，显示出现EXEC_BAD_ACCESS前访问的最后一个object，下面是具体的步骤：
a、在每一个类而且在 other c flags中加入-D _FOR_DEBUG_（记住请只在Debug Configuration下加入此标记）。这样当你程序崩溃时，Xcode的console上就会准确地记录了最后运行的object的方法。的实现文件（.m,.mm）文件中，添加以下代码：
[cpp] 
-(BOOL) respondsToSelector : (SEL)aSelector { 
    printf("SELECTOR: %s\n", [NSStringFromSelector(aSelector) UTF8String]); 
    return [super respondsToSelector:aSelector]; 
} 

b、而且在 other c flags中加入-D _FOR_DEBUG_（记住请只在Debug Configuration下加入此标记）。这样当你程序崩溃时，Xcode的console上就会准确地记录了最后运行的object的方法。

三、让XCode反馈足够多的信息

在Edit–>Scheme里面 找到Arguments ,在Environment Variables这里添加
把下面2个值设置成YES
NSAutoreleaseFreedObjectCheckEnabled
NSDebugEnabled
这种方法很是好用，建议在创建一个工程的时候，加入此设置

四、设置全局异常断点

在程序抛出异常时候，每每须要定位到异常
键入快捷键 cmd + 6 进入断点窗口，点击左下角的"+"按钮，选择弹出框的“Add Exception BreakPoint”项，以下图所示：

而后使用默认设置，点击"done"按钮，设置全局异常断点就完成了