C++博客-佳为好友-随笔分类-Debug-GDB

原：查看retain和release的历史记录

佳为好友 — Sat, 29 Dec 2012 03:10:00 GMT

创建：2011.10.06
修改：2011.11.03：增加循环引用的检测。

malloc_history只能查看alloc和dealloc的历史，看不到retain和release的历史，但是Instruments却可以，我们可以利用之。

思路是：对想查看的对象进行过度的release，这样就可以利用Instruments来查看了。

简单的方法如下：

static id sNeedReleaseObj = nil;

@interface TTT : NSObject

- (void)releaseUntilCrash;

@end

@implementation TTT

- (void)delayReleaseUntilCrash

{

if (sNeedReleaseObj == nil) {

return;

}

for (int pos=0; pos<10000; pos++) {

[sNeedReleaseObj release];

}

- (void)releaseUntilCrash

{

[self performSelector:@selector(delayReleaseUntilCrash) withObject:nil afterDelay:10.0f];

}

@end

调用的时候，可以用：

TTT *ttt = [[TTT alloc] init];

sNeedReleaseObj = csvDict;

[ttt performSelectorOnMainThread:@selector(releaseUntilCrash) withObject:nil waitUntilDone:NO];

csvDict一定会Crash的，然后就可以查看csvDict的retain和release历史记录了。

＝＝＝＝＝
对于循环引用，也就是A强引用B，B有强引用A，导致AB都无法释放的问题。例如：

- (IBAction)onBtnPressed:(id)sender {

    A *a = [[A alloc] init];
    B *b = [[B alloc] init];
    a.b = b;
    b.a = a;

    [a release];
    [b release];

    TTT *ttt = [[TTT alloc] init];
    sNeedReleaseObj = a;
    [ttt performSelectorOnMainThread:@selector(releaseUntilCrash) withObject:nil waitUntilDone:NO];

}

如果不加入TTT，则上面的代码中，A和B都无法释放。
加入TTT之后，查看Instruments的结果如下：

注意：在倒数2次TTT的调用中间，会有一次-[B dealloc]，这在正常释放的情况下是不存在的，只有发生了双重引用才会出现这个问题。这说明在A和B循环引用了。因为，TTT释放的是A，而上述图例中出现了B，因此说明A和B循环引用了，这样就可以直接确定循环引用的2个对象了。
循环引用是很难发现的，因为它即不是内存泄露，也不会出现内存崩溃，只是始终霸占着内存不释放。只有通过Instruments的Allocations，才能大约判断是哪个对象没有正确释放，然后在使用TTT来查找出来。

＋＋＋＋＋

佳为好友 2012-12-29 11:10 发表评论

转：Enabling Remote Debugging via Private APIs in Mobile Safari

佳为好友 — Sat, 29 Dec 2012 02:51:00 GMT

创建：2012.08.06

转：http://atnan.com/blog/2011/11/17/enabling-remote-debugging-via-private-apis-in-mobile-safari/

Enabling Remote Debugging via Private APIs in Mobile Safari

NOV 17TH, 2011

The WebKit Web Inspector in Safari & Chrome is part of every decent web developer’s toolkit, but unfortunately it’s unavailable in Mobile Safari.

Or is it?

While I was researching my previous article on enabling WebGL on iOS via private WebKit APIs, another API caught my eye while I was class-dumping the private WebKit.framework.

Private WebView API

1 2 3

@interface WebView (WebPrivate) + (void)_enableRemoteInspector; @end

I did a little bit of research and found an article by Pavel Feldman (@repenaxa) on the Surfin’ Safari blog about WebKit’s remote debugging feature. This private +[WebView _enableRemoteInspector]API enables those same features in mobile WebKit.

Note: This API is available as of iOS 5.0. To use it, you’ll need a copy of Xcode with the iOS 5.0 SDK. You’ll also need to make sure that if you’ve got the iOS 4.0 SDK installed alongside the iOS 5.0 SDK, that you’ve selected iOS 5.0 in the iPhone Simulator via the Hardware → Version menu. Hat tip to Phil Oye (@philoye) for pointing that out.

Enabling remote debugging in a `UIWebView`

To see if I could get it working, I checked out a copy of my UIWebViewWebGL project, and called the private API in application:didFinishLaunchingWithOptions:

Enabling the remote inspector on launch

1 2 3 4 5

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {   // ...Snipped...   [NSClassFromString(@"WebView") _enableRemoteInspector];   // ...Snipped... }

The Surfin’ Safari article said the remote debugger runs on port 9222, but connecting to http://localhost:9222 while the app was running in the simulator didn’t seem to work.

Using lsof showed that UIWebViewWebGL.app was actually listening on port 9999:

$ sudo lsof -i TCP -a -p $(pidof UIWebViewWebGL) -P COMMAND    PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME UIWebView 3748 nathan    9u  IPv6 0xffffff800fa25d80      0t0  TCP localhost:9999 (LISTEN) UIWebView 3748 nathan   13u  IPv6 0xffffff80111ba340      0t0  TCP localhost:9999->localhost:52483 (ESTABLISHED)

Now when I pointed my browser at http://localhost:9999, it worked!

Logging document.location.href in the web inspector console shows I’m successfully inspecting the web content from UIWebViewWebGL.app running in the iPhone Simulator.

Huzzah!

Enabling remote debugging in Mobile Safari

Enabling the web inspector in an embedded UIWebView is handy, but what about content running in Mobile Safari?

To do that, we need to call the +[WebView _enableRemoteInspector] API from within the Mobile Safari app. The easiest way to do that is by launching Mobile Safari in the iPhone Simulator, and then use gdb to attach to it and call the private API.

Script to enable the remote inspector in Mobile Safari

1 2 3 4 5 6 7 8 9 10 11 12 13

MobileSafari_PID=$(ps x | grep "MobileSafari" | grep -v grep | awk '{ print $1 }')  if [ "$MobileSafari_PID" == "" ]; then  echo "Mobile Safari.app must be running in the Simulator to enable the remote inspector." else    cat < /dev/null   attach $MobileSafari_PID   p (void *)[WebView _enableRemoteInspector]   detach EOM  fi

Browsing to http://localhost:9999 will show an index page listing the URL of each tab open in Mobile Safari. This allows you to have a remote inspector open for each tab in Mobile Safari.

Summing Up

I haven’t used the remote inspector in anger yet, but so far it’s been incredibly useful.

Note that you can’t use gdb to inject code on a device, so enabling remote debugging in Mobile Safari is limited to the Simulator. Hopefully Apple will provide the option to enable it, much like the debug console in Settings → Safari → Advanced → Debug Console.

~~In the meantime, you can load your web content in an embedded UIWebView.~~ Enabling the remote inspector on a UIWebView in an app running on the device doesn’t seem to work. Using nmapshows that my iPhone only has port 62078 open for OTA syncing, so it’s likely there’s a firewall preventing connections to the remote inspector port.

＋＋＋＋＋

佳为好友 2012-12-29 10:51 发表评论

原:gdb与时间戳

佳为好友 — Thu, 27 Dec 2012 05:28:00 GMT

创建:2012年12月27日

gdb

使用while循环打印ctime失败。

不得已，在代码中定义了一个临时函数

- (NSDate *)getTTT:(NSTimeInterval)tt

{

return [NSDate dateWithTimeIntervalSince1970:tt];

}

(gdb) p $p=0

$828 = 0

(gdb) while ($p<$c)

>p $ttt = (double)[(NSNumber *)[$ts objectAtIndex:$p] doubleValue]

>po [self getTTT:$ttt]

>p $p++

>end

$829 = 1351569600

2012-10-30 04:00:00 +0000

$830 = 0

$831 = 1351570500

2012-10-30 04:15:00 +0000

$832 = 1

$833 = 1351571400

2012-10-30 04:30:00 +0000

$834 = 2

$835 = 1351572300

2012-10-30 04:45:00 +0000

$836 = 3

$837 = 1351573200

2012-10-30 05:00:00 +0000

$838 = 4

$839 = 1351574100

2012-10-30 05:15:00 +0000

$840 = 5

$841 = 1351575000

2012-10-30 05:30:00 +0000

$842 = 6

$843 = 1351575900

2012-10-30 05:45:00 +0000

$844 = 7

$845 = 1351576800

2012-10-30 06:00:00 +0000

$846 = 8

$847 = 1351577700

2012-10-30 06:15:00 +0000

$848 = 9

$849 = 1351578600

2012-10-30 06:30:00 +0000

$850 = 10

$851 = 1351579500

2012-10-30 06:45:00 +0000

$852 = 11

$853 = 1351580400

2012-10-30 07:00:00 +0000

$854 = 12

$855 = 1351581300

2012-10-30 07:15:00 +0000

$856 = 13

$857 = 1351582200

2012-10-30 07:30:00 +0000

$858 = 14

$859 = 1351583100

2012-10-30 07:45:00 +0000

$860 = 15

$861 = 1351584000

2012-10-30 08:00:00 +0000

$862 = 16

$863 = 1351584900

2012-10-30 08:15:00 +0000

$864 = 17

$865 = 1351585800

2012-10-30 08:30:00 +0000

$866 = 18

$867 = 1351586700

2012-10-30 08:45:00 +0000

$868 = 19

$869 = 1351587600

2012-10-30 09:00:00 +0000

$870 = 20

$871 = 1351589400

2012-10-30 09:30:00 +0000

$872 = 21

$873 = 1351590300

2012-10-30 09:45:00 +0000

$874 = 22

$875 = 1351597500

2012-10-30 11:45:00 +0000

$876 = 23

$877 = 1351638000

2012-10-30 23:00:00 +0000

$878 = 24

$879 = 1351645200

2012-10-31 01:00:00 +0000

$880 = 25

$881 = 1351646100

2012-10-31 01:15:00 +0000

$882 = 26

$883 = 1351647000

2012-10-31 01:30:00 +0000

$884 = 27

$885 = 1351647900

2012-10-31 01:45:00 +0000

$886 = 28

$887 = 1351648800

2012-10-31 02:00:00 +0000

$888 = 29

$889 = 1351649700

2012-10-31 02:15:00 +0000

$890 = 30

$891 = 1351650600

2012-10-31 02:30:00 +0000

$892 = 31

$893 = 1351651500

2012-10-31 02:45:00 +0000

$894 = 32

$895 = 1351652400

2012-10-31 03:00:00 +0000

$896 = 33

$897 = 1351653300

2012-10-31 03:15:00 +0000

$898 = 34

$899 = 1351654200

2012-10-31 03:30:00 +0000

$900 = 35

$901 = 1351656000

2012-10-31 04:00:00 +0000

$902 = 36

$903 = 1351656900

2012-10-31 04:15:00 +0000

$904 = 37

$905 = 1351657800

2012-10-31 04:30:00 +0000

$906 = 38

$907 = 1351658700

2012-10-31 04:45:00 +0000

$908 = 39

$909 = 1351659600

2012-10-31 05:00:00 +0000

$910 = 40

$911 = 1351660500

2012-10-31 05:15:00 +0000

$912 = 41

$913 = 1351661400

2012-10-31 05:30:00 +0000

$914 = 42

$915 = 1351662300

2012-10-31 05:45:00 +0000

$916 = 43

$917 = 1351663200

2012-10-31 06:00:00 +0000

$918 = 44

$919 = 1351664100

2012-10-31 06:15:00 +0000

$920 = 45

$921 = 1351665000

2012-10-31 06:30:00 +0000

$922 = 46

$923 = 1351665900

2012-10-31 06:45:00 +0000

$924 = 47

$925 = 1351666800

2012-10-31 07:00:00 +0000

$926 = 48

$927 = 1351667700

2012-10-31 07:15:00 +0000

$928 = 49

$929 = 1351668600

2012-10-31 07:30:00 +0000

$930 = 50

$931 = 1351669500

2012-10-31 07:45:00 +0000

$932 = 51

$933 = 1351670400

2012-10-31 08:00:00 +0000

$934 = 52

$935 = 1351671300

2012-10-31 08:15:00 +0000

$936 = 53

$937 = 1351672200

2012-10-31 08:30:00 +0000

$938 = 54

$939 = 1351673100

2012-10-31 08:45:00 +0000

$940 = 55

$941 = 1351674000

2012-10-31 09:00:00 +0000

$942 = 56

$943 = 1351702800

2012-10-31 17:00:00 +0000

$944 = 57

$945 = 1351724400

2012-10-31 23:00:00 +0000

$946 = 58

$947 = 1351731600

2012-11-01 01:00:00 +0000

$948 = 59

$949 = 1351732500

2012-11-01 01:15:00 +0000

$950 = 60

$951 = 1351733400

2012-11-01 01:30:00 +0000

$952 = 61

$953 = 1351734300

2012-11-01 01:45:00 +0000

$954 = 62

$955 = 1351735200

2012-11-01 02:00:00 +0000

$956 = 63

$957 = 1351736100

2012-11-01 02:15:00 +0000

$958 = 64

$959 = 1351737000

2012-11-01 02:30:00 +0000

$960 = 65

$961 = 1351737900

2012-11-01 02:45:00 +0000

$962 = 66

$963 = 1351738800

2012-11-01 03:00:00 +0000

$964 = 67

$965 = 1351739700

2012-11-01 03:15:00 +0000

$966 = 68

$967 = 1351740600

2012-11-01 03:30:00 +0000

$968 = 69

$969 = 1351742400

2012-11-01 04:00:00 +0000

$970 = 70

$971 = 1351743300

2012-11-01 04:15:00 +0000

$972 = 71

$973 = 1351744200

2012-11-01 04:30:00 +0000

$974 = 72

$975 = 1351745100

2012-11-01 04:45:00 +0000

$976 = 73

$977 = 1351746000

2012-11-01 05:00:00 +0000

$978 = 74

$979 = 1351746900

2012-11-01 05:15:00 +0000

$980 = 75

$981 = 1351747800

2012-11-01 05:30:00 +0000

$982 = 76

$983 = 1351748700

2012-11-01 05:45:00 +0000

$984 = 77

$985 = 1351749600

2012-11-01 06:00:00 +0000

$986 = 78

$987 = 1351750500

2012-11-01 06:15:00 +0000

$988 = 79

$989 = 1351751400

2012-11-01 06:30:00 +0000

$990 = 80

$991 = 1351752300

2012-11-01 06:45:00 +0000

$992 = 81

$993 = 1351753200

2012-11-01 07:00:00 +0000

$994 = 82

$995 = 1351754100

2012-11-01 07:15:00 +0000

$996 = 83

$997 = 1351755000

2012-11-01 07:30:00 +0000

$998 = 84

$999 = 1351755900

2012-11-01 07:45:00 +0000

$1000 = 85

$1001 = 1351756800

2012-11-01 08:00:00 +0000

$1002 = 86

$1003 = 1351757700

2012-11-01 08:15:00 +0000

$1004 = 87

$1005 = 1351758600

2012-11-01 08:30:00 +0000

$1006 = 88

$1007 = 1351759500

2012-11-01 08:45:00 +0000

$1008 = 89

$1009 = 1351760400

2012-11-01 09:00:00 +0000

$1010 = 90

$1011 = 1351810800

2012-11-01 23:00:00 +0000

$1012 = 91

$1013 = 1351816200

2012-11-02 00:30:00 +0000

$1014 = 92

$1015 = 1351818000

2012-11-02 01:00:00 +0000

$1016 = 93

$1017 = 1351818900

2012-11-02 01:15:00 +0000

$1018 = 94

$1019 = 1351819800

2012-11-02 01:30:00 +0000

$1020 = 95

$1021 = 1351820700

2012-11-02 01:45:00 +0000

$1022 = 96

$1023 = 1351821600

2012-11-02 02:00:00 +0000

$1024 = 97

$1025 = 1351822500

2012-11-02 02:15:00 +0000

$1026 = 98

$1027 = 1351823400

2012-11-02 02:30:00 +0000

$1028 = 99

$1029 = 1351824300

2012-11-02 02:45:00 +0000

$1030 = 100

$1031 = 1351825200

2012-11-02 03:00:00 +0000

$1032 = 101

$1033 = 1351826100

2012-11-02 03:15:00 +0000

$1034 = 102

$1035 = 1351827000

2012-11-02 03:30:00 +0000

$1036 = 103

$1037 = 1351828800

2012-11-02 04:00:00 +0000

$1038 = 104

$1039 = 1351829700

2012-11-02 04:15:00 +0000

$1040 = 105

$1041 = 1351830600

2012-11-02 04:30:00 +0000

$1042 = 106

$1043 = 1351831500

2012-11-02 04:45:00 +0000

$1044 = 107

$1045 = 1351832400

2012-11-02 05:00:00 +0000

$1046 = 108

$1047 = 1351833300

2012-11-02 05:15:00 +0000

$1048 = 109

$1049 = 1351834200

2012-11-02 05:30:00 +0000

$1050 = 110

$1051 = 1351835100

2012-11-02 05:45:00 +0000

$1052 = 111

$1053 = 1351836000

2012-11-02 06:00:00 +0000

$1054 = 112

$1055 = 1351836900

2012-11-02 06:15:00 +0000

$1056 = 113

$1057 = 1351837800

2012-11-02 06:30:00 +0000

$1058 = 114

$1059 = 1351838700

2012-11-02 06:45:00 +0000

$1060 = 115

$1061 = 1351839600

2012-11-02 07:00:00 +0000

$1062 = 116

$1063 = 1351840500

2012-11-02 07:15:00 +0000

$1064 = 117

$1065 = 1351841400

2012-11-02 07:30:00 +0000

$1066 = 118

$1067 = 1351842300

2012-11-02 07:45:00 +0000

$1068 = 119

$1069 = 1351843200

2012-11-02 08:00:00 +0000

$1070 = 120

$1071 = 1351844100

2012-11-02 08:15:00 +0000

$1072 = 121

$1073 = 1351845000

2012-11-02 08:30:00 +0000

$1074 = 122

$1075 = 1351845900

2012-11-02 08:45:00 +0000

$1076 = 123

$1077 = 1351846800

2012-11-02 09:00:00 +0000

$1078 = 124

$1079 = 1351881000

2012-11-02 18:30:00 +0000

$1080 = 125

$1081 = 1351882800

2012-11-02 19:00:00 +0000

$1082 = 126

$1083 = 1351884600

2012-11-02 19:30:00 +0000

$1084 = 127

$1085 = 1351886400

2012-11-02 20:00:00 +0000

$1086 = 128

$1087 = 1352077200

2012-11-05 01:00:00 +0000

$1088 = 129

$1089 = 1352078100

2012-11-05 01:15:00 +0000

$1090 = 130

$1091 = 1352079000

2012-11-05 01:30:00 +0000

$1092 = 131

$1093 = 1352079900

2012-11-05 01:45:00 +0000

$1094 = 132

$1095 = 1352080800

2012-11-05 02:00:00 +0000

$1096 = 133

$1097 = 1352081700

2012-11-05 02:15:00 +0000

$1098 = 134

$1099 = 1352082600

2012-11-05 02:30:00 +0000

$1100 = 135

$1101 = 1352083500

2012-11-05 02:45:00 +0000

$1102 = 136

$1103 = 1352084400

2012-11-05 03:00:00 +0000

$1104 = 137

$1105 = 1352085300

2012-11-05 03:15:00 +0000

$1106 = 138

$1107 = 1352086200

2012-11-05 03:30:00 +0000

$1108 = 139

$1109 = 1352087100

2012-11-05 03:45:00 +0000

$1110 = 140

$1111 = 1352088000

2012-11-05 04:00:00 +0000

$1112 = 141

$1113 = 1352088900

2012-11-05 04:15:00 +0000

$1114 = 142

$1115 = 1352089800

2012-11-05 04:30:00 +0000

$1116 = 143

$1117 = 1352091600

2012-11-05 05:00:00 +0000

$1118 = 144

$1119 = 1352092500

2012-11-05 05:15:00 +0000

$1120 = 145

$1121 = 1352093400

2012-11-05 05:30:00 +0000

$1122 = 146

$1123 = 1352094300

2012-11-05 05:45:00 +0000

$1124 = 147

$1125 = 1352095200

2012-11-05 06:00:00 +0000

$1126 = 148

$1127 = 1352096100

2012-11-05 06:15:00 +0000

$1128 = 149

$1129 = 1352097000

2012-11-05 06:30:00 +0000

$1130 = 150

$1131 = 1352097900

2012-11-05 06:45:00 +0000

$1132 = 151

$1133 = 1352098800

2012-11-05 07:00:00 +0000

$1134 = 152

$1135 = 1352099700

2012-11-05 07:15:00 +0000

$1136 = 153

$1137 = 1352100600

2012-11-05 07:30:00 +0000

$1138 = 154

$1139 = 1352101500

2012-11-05 07:45:00 +0000

$1140 = 155

$1141 = 1352102400

2012-11-05 08:00:00 +0000

$1142 = 156

$1143 = 1352103300

2012-11-05 08:15:00 +0000

$1144 = 157

$1145 = 1352104200

2012-11-05 08:30:00 +0000

$1146 = 158

$1147 = 1352105100

2012-11-05 08:45:00 +0000

$1148 = 159

$1149 = 1352106000

2012-11-05 09:00:00 +0000

$1150 = 160

$1151 = 1352110500

2012-11-05 10:15:00 +0000

$1152 = 161

$1153 = 1352111400

2012-11-05 10:30:00 +0000

$1154 = 162

$1155 = 1352131200

2012-11-05 16:00:00 +0000

$1156 = 163

$1157 = 1352132100

2012-11-05 16:15:00 +0000

$1158 = 164

$1159 = 1352156400

2012-11-05 23:00:00 +0000

$1160 = 165

$1161 = 1352163600

2012-11-06 01:00:00 +0000

$1162 = 166

$1163 = 1352164500

2012-11-06 01:15:00 +0000

$1164 = 167

$1165 = 1352165400

2012-11-06 01:30:00 +0000

$1166 = 168

$1167 = 1352166300

2012-11-06 01:45:00 +0000

$1168 = 169

$1169 = 1352167200

2012-11-06 02:00:00 +0000

$1170 = 170

$1171 = 1352168100

2012-11-06 02:15:00 +0000

$1172 = 171

$1173 = 1352169000

2012-11-06 02:30:00 +0000

$1174 = 172

$1175 = 1352169900

2012-11-06 02:45:00 +0000

$1176 = 173

$1177 = 1352170800

2012-11-06 03:00:00 +0000

$1178 = 174

$1179 = 1352171700

2012-11-06 03:15:00 +0000

$1180 = 175

$1181 = 1352172600

2012-11-06 03:30:00 +0000

$1182 = 176

$1183 = 1352173500

2012-11-06 03:45:00 +0000

$1184 = 177

$1185 = 1352174400

2012-11-06 04:00:00 +0000

$1186 = 178

$1187 = 1352175300

2012-11-06 04:15:00 +0000

$1188 = 179

$1189 = 1352178000

2012-11-06 05:00:00 +0000

$1190 = 180

$1191 = 1352178900

2012-11-06 05:15:00 +0000

$1192 = 181

$1193 = 1352179800

2012-11-06 05:30:00 +0000

$1194 = 182

$1195 = 1352180700

2012-11-06 05:45:00 +0000

$1196 = 183

$1197 = 1352181600

2012-11-06 06:00:00 +0000

$1198 = 184

$1199 = 1352182500

2012-11-06 06:15:00 +0000

$1200 = 185

$1201 = 1352183400

2012-11-06 06:30:00 +0000

$1202 = 186

$1203 = 1352184300

2012-11-06 06:45:00 +0000

$1204 = 187

$1205 = 1352185200

2012-11-06 07:00:00 +0000

$1206 = 188

$1207 = 1352186100

2012-11-06 07:15:00 +0000

$1208 = 189

$1209 = 1352187000

2012-11-06 07:30:00 +0000

$1210 = 190

$1211 = 1352187900

2012-11-06 07:45:00 +0000

$1212 = 191

$1213 = 1352188800

2012-11-06 08:00:00 +0000

$1214 = 192

$1215 = 1352189700

2012-11-06 08:15:00 +0000

$1216 = 193

$1217 = 1352190600

2012-11-06 08:30:00 +0000

$1218 = 194

$1219 = 1352191500

2012-11-06 08:45:00 +0000

$1220 = 195

$1221 = 1352192400

2012-11-06 09:00:00 +0000

$1222 = 196

(gdb)

+++++

佳为好友 2012-12-27 13:28 发表评论

原:gdb

佳为好友 — Thu, 27 Dec 2012 05:23:00 GMT

创建:2012年12月27日

u 跳出循环。相当与next命令，但是在循环的时候不进入循环体。

u 123 直到第123行才停下。相当于在第123行打下一个临时的断点。

WhatGDBDoesDuringStartup

1. Executes all commands from system init file

2. Executes all the commands from ~/.gdbinit

3. Process command line options and operands

4. Executes all the commands from ./.gdbinit

5. reads command files specified by the `-x' option

6. ...

Automating tasks - history, recording

• continue What GDB Does During Startup

... 6. Reads the command history recorded in the history file.

• (gdb) set history filename fname (gdb) set history save on/off

• (gdb) show history

• (gdb) show commands

+++

Sending messages to objects while debugging Objective-C in gdb, without symbols

If you must override gdb and send a message to an object when it will not let you, you can use performSelector:

(gdb) print (int)[receivedData count]

Target does not respond to this message selector.

(gdb) print (int)[receivedData performSelector:@selector(count) ]

2008-09-15 00:46:35.854 Executable[1008:20b] *** -[NSConcreteMutableData count]:

unrecognized selector sent to instance 0x105f2e0

If you need to pass an argument use withObject:

(gdb) print (int)[receivedData performSelector:@selector(count) withObject:myObject ]

po (id)objc_msgSend(JSONObject, @selector(class))

+++

gdb输出长字符串

最好的方法：

call (void)puts(your_string)

puts能把字符串输出到终端。

次好的方法：

set print elements 0

set print elements number-of-elements命令能设定print的输出长度。如果number-of-elements为0，则输出没有限制。默认限制是200.

+++

检查你的OS是否支持watchpoint，

gdb$ show can-use-hw-watchpoints

Debugger's willingness to use watchpoint hardware is 1.

++++

tbreak: Break once, and then remove the breakpoint

rbreak: break on function matching regular expression

+++

打印STL的内容

http://sourceware.org/gdb/wiki/STLSupport?action=AttachFile&do=view&target=stl-views-1.0.3.gdb

=====

lsof 显示当前所有进程打开的文件

nm 显示一个文件的symbol table。

+++++

佳为好友 2012-12-27 13:23 发表评论

原：使用Crash文件的步骤和原理 -3

佳为好友 — Wed, 26 Dec 2012 01:59:00 GMT

摘要: 创建：2011.06.22 修改：2012.04.18 修改：2012.04.24 ＊使用Crash文件的步骤：＃源代码上传并tag一个版本。＃生成AdHoc包。Release或者Debug都可以。＃生成xcarchive文件。保存该文件到某个你习惯的路径。＃得到ipa包。＃发布到手机。＃产生异常。＃连接手机和mac。＃在CrashLog中得到Crash的log。＃查看l... 阅读全文

佳为好友 2012-12-26 09:59 发表评论

原：gdb高级技巧 -2

佳为好友 — Wed, 26 Dec 2012 01:56:00 GMT

创建：2012年10月25日

增加：2012年11月29日

*函数的返回值保存在$eax中。

因此，如果你在一个函数中调用finish，结束该函数后，调用po $eax可以查看返回值。

*如果你调用(gdb) x/10i $pc得到一些地址，并且想在某个地址上加上断点，那么你需要使用*。例如：

(gdb) disassemble main

Dump of assembler code for function main:

0x0046c050 : push ebp

0x0046c051 : mov ebp,esp

0x0046c053 : push ebx

0x0046c054 : push edi

0x0046c055 : push esi

0x0046c056 : sub esp,0x2c

0x0046c059 : call 0x46c05e

0x0046c05e : pop eax

0x0046c05f : mov ecx,DWORD PTR [ebp+0xc]

(gdb) b *0x0046c05f // 就是这里，需要加入一个*

Breakpoint 8 at 0x46c05f: file main.m, line 14.

No symbol "null" in current context.

(gdb)

*有时候编译器会自动优化程序，导致一些变量消失了。如果希望编译器不要优化掉它们，可以将它们声明为volatile类型。例如：

volatile int k = 23;

k++;

这样k就不会被优化掉了。

*在objc_exception_throw设定一个断点就可以捕获所有的抛出的异常。在XCode中可以直接通过UI设定。

+++++

佳为好友 2012-12-26 09:56 发表评论

原：gdb user command file

佳为好友 — Wed, 26 Dec 2012 01:55:00 GMT

创建：2012年11月02日

参考：

http://www.adacore.com/adaanswers/gems/gem-119-gdb-scripting-part-1

http://www.adacore.com/adaanswers/gems/gem-120-gdb-scripting-part-2

http://www.praetorian.com/blog/building-a-basic-fuzzer-with-gdb-the-five-minute-gdb-scripting-tutorial

user command文件可以放在~/.gdbinit , 也可以使用source命令

(gdb) source /xxx/xx.gdb

This language follows the following format:

define _command_

_code_

end

document _command_

_help text_

end

$arg0

$arg1

$arg2

...

最多10个参数，即$arg9

$argc是参数的个数。if $argc == 0 xxx

设置变量

set $VAR = 0

set $byte = *(unsigned char *)$arg0

if语句

if _expression_

_statements_

else

_statements_

end

while 语句

while _expression_

_statements_

end

输出

echo _text_

echo可以识别非c-style string。例如，\n.

echo也不会输出newline，除非你指定\n。

output _expression_

output只输出_expression_的值，不会输出newline，也不会输出`$nn = '

printf _string_, _expressions_...

printf有格式化的能力。printf "foo, bar-foo = 0x%x, 0x%x\n", foo, bar-foo

gdb有一个默认的user command，叫做hook-stop，它在每次gdb停下来的时候执行。你可以改写它。

define hook-stop

eflags

end

document hook-stop

/!\ For internal use only - do not call manually /!\

end

一个随机数的例子

define build_fuzz_buf

set $size = $arg0

call (char *)malloc($size)

set $buf = $

set $i = 0

call (int)time(0)

set $time = $

call (int) srand($time)

while $i < $size

call (char) rand()

set *(char *)($buf + $i) = $

set $i = $i+1

end

printf “buf: 0xx len: %d\n”, $buf, $size

p $buf

end

+++++

佳为好友 2012-12-26 09:55 发表评论

原：gdb与dateWithTimeIntervalSince1970的bug

佳为好友 — Wed, 26 Dec 2012 01:55:00 GMT

创建：2012年10月31日

当使用gdb调试dateWithTimeIntervalSince1970时出现bug，

po [NSDate dateWithTimeIntervalSince1970:123]

得到的始终是1970年

可以使用ctime，如下：

(gdb) p (char *)ctime(&{123})

$6 = 0x4b99cf6 "Thu Jan 1 08:02:03 1970\n"

(gdb)

+++++

佳为好友 2012-12-26 09:55 发表评论

转：Inspecting Obj-C parameters in gdb -好

佳为好友 — Wed, 26 Dec 2012 01:54:00 GMT

创建：2012年10月24日

转：http://www.clarkcox.com/blog/2009/02/04/inspecting-obj-c-parameters-in-gdb/

Since the addition of i386 and x86_64 to the Mac OS’s repertoire several years back, remembering which registers are used for what has become difficult, and this can complicate the debugging of code for which you have no symbols. So here is my cheat-sheet (posted here, mostly so that I can find it again without google-ing for old mailing list posts; but, I figure someone else may find it useful as well):

arm (before prolog)

$r0 ➡ arg0 (self)
$r1 ➡ arg1 (_cmd)
$r2 ➡ arg2
$r3 ➡ arg3
*($sp) ➡ arg4
*($sp+4) ➡ arg5
*($sp+8) ➡ arg6

ppc/ppc64

$r3 ➡ arg0 (self)
$r4 ➡ arg1 (_cmd)
$r5 ➡ arg2
$r6 ➡ arg3
$r7 ➡ arg4
$r8 ➡ arg5

i386 (before prolog)

*($esp+4n) ➡ arg(n)
*($esp) ➡ arg0 (self)
*($esp+4) ➡ arg1 (_cmd)
*($esp+8) ➡ arg2
*($esp+12) ➡ arg3
*($esp+16) ➡ arg4
*($esp+20) ➡ arg5

i386 (after prolog)

*($ebp+8+4n) ➡ arg(n)
*($ebp+4) ➡ Return addr
*($ebp+8) ➡ arg0 (self)
*($ebp+12) ➡ arg1 (_cmd)
*($ebp+16) ➡ arg2
*($ebp+20) ➡ arg3
*($ebp+24) ➡ arg4
*($ebp+28) ➡ arg5
*($ebp) ➡ Previous $ebp

x86_64

$rdi ➡ arg0 (self)
$rsi ➡ arg1 (_cmd)
$rdx ➡ arg2
$rcx ➡ arg3
$r8 ➡ arg4
$r9 ➡ arg5

So, if you have a method defined as:
-(id)method:(id)foo bar:(id)bar baz:(id)baz
you can print each of the parameters with:

	arm	ppc/ppc64	x86_64	i386 (before prolog)	i386 (after prolog)
self	`po $r0`	`po $r3`	`po $rdi`	`po (id)($esp)`	`po (id)($ebp+8)`
_cmd	`p (SEL)$r1`	`p (SEL)$r4`	`p (SEL)$rsi`	`p (SEL)($esp+4)`	`p (SEL)($ebp+12)`
foo	`po $r2`	`po $r5`	`po $rdx`	`po (id)($esp+8)`	`po (id)($ebp+16)`
bar	`po $r3`	`po $r6`	`po $rcx`	`po (id)($esp+12)`	`po (id)($ebp+20)`
baz	`po (id)($sp)`	`po $r7`	`po $r8`	`po (id)($esp+16)`	`po (id)($ebp+24)`

As Blake mentioned in his comment, on i386, if you’re at the beginning of a function or method, before the prolog has executed (i.e. the bit of code responsible for saving registers, adjusting the stack pointer, etc.), then ebp won’t have been set up for you yet.
So, I’ve amended the above table.

That complexity is another reason I long for the simplicity of PowerPC asm, not to mention M68k asm; at least x86_64 has made the step towards using registers for parameters where possible.

Edited to add: In case it isn’t obvious, these particular stack offsets and registers assignments only make sense when dealing with pointer and integer parameters and return values. When structures and floating point values come into the mix, things can get more complicated.

Edited to add: I’ve added registers/stack offsets for arm. But note that these are for before the prolog has executed. Arm code seems much looser about what happens in its function prologs, so there really isn’t a standard layout post-prolog

+++++

佳为好友 2012-12-26 09:54 发表评论

原：检查内存泄露的思路 --2

佳为好友 — Wed, 26 Dec 2012 01:54:00 GMT

创建：2011.10.10

修改：2012.10.22

首先，使用XCode的静态解析工具，尽量去掉内存泄露的地方。
然后，使用Leaks工具找到内存泄露的对象。记得选择Leaks，并去掉每10s的自动解析功能，要手动解析，因为这样运行起来会比较快。
按照先易后难的方法解决每个Leak，有时候你会发现，那些比较难的Leak，会随着简单的Leak的解决而消失。
结合Zombies来解决Leaks。

比较复杂的Leaks：
Leak发生在系统函数中。
随机的Leak。
只有真机才出现的Leak。无法使用Zombies。
程序太大了，导致无法使用Leaks程序解析。

2012年10月22日：
使用Instrument解决MemoryLeaks步骤

*不要被Memory Leaks的数量吓到，有些Leak其实可能只是因为一个对象的泄露导致的。因此，总体思路是从易到难，从熟悉到陌生的类。
*首先浏览全部的Memory Leaks，找到那些是我们自定义的类的泄露，从这些类开始解决。

因为系统的类不容易解决内存泄露，因为要么它们发生在系统内部，要么使用的太过频繁，而且很多都是由于我们自己的类的泄露导致的。

而我们自己的类，则使用范围比较窄，容易找到原因。

*浏览对象泄露的历史，查看“Responsible Library”，看这些Library中，哪些是我们的软件，哪些是系统的（如，Foundation, UIKit)，先查看我们自己软件的。

一一对照我们自己软件的历史，看看它们是否是配对的。如果不是，则泄露在我们内部了。如果是，则可能是调用系统函数出错，导致了泄露。此时，在依次查看每个系统的Library调用，看看它们是否是一一匹配的。

总之，要根据Library的来查看配对，而不应该根据内存引用计数的历史过程来查找泄露。

＋＋＋＋＋

佳为好友 2012-12-26 09:54 发表评论

原：常用GDB命令

佳为好友 — Wed, 26 Dec 2012 01:53:00 GMT

创建：2012.10.19

+++

Help

(gdb) h -- h is for help -- list of help topics

(gdb) h topic -- help on named topic

(gdb) h bt -- help on bt command

+++

Stopping And Continuing

5.1 Breakpoints, Watchpoints, and Catchpoints

(gdb) b

(gdb) b 36 - break at line number 36 of current source file

(gdb) b fn.c:22 - break at line number 22 of source file fn.c which

is compiled into this executable

(gdb) b [NSNotificationCenter postNotificationName:object:]

(gdb) i b - info breakpoints. Lists all breakpoints now set up.

(gdb) break frik.c:13 thread 28 -只在thread28上设置断点

(gdb) watch var - w

(gdb) rwatch var - r

(gdb) awatch var - r/w

(gdb) i watchpoints -

(gdb) d - delete all breakpoints

(gdb) d 4 - delete #4 breakpoint

(gdb) dis - disable all breakpoints

(gdb) dis 4 - disable #4 breakpoint

(gdb) enable - enable all breakpoints

(gdb) enable 4 - enable #4 breakpoint

(gdb) b 36 if i==3 - b and condition

(gdb) condition 4 i==3 - condition #4 breakpoint

(gdb) condition 4 - remove condition #4 breakpoint

(gdb) ignore 4 10 - ignore #4 breakpoint for 10 times.

(gdb) ignore 4 0 - remove ignore for #4 breakpoint

(gdb) c 10 - continue, and ignore next 10 times.

(gdb) commands 4 - add commands

silent

printf "x is %d\n",x

end

(gdb) commands 4 - remove commands

end

5.2 Continuing and Stepping

(gdb) c

(gdb) n - next

(gdb) n 2 - next 2 line.

(gdb) ni

(gdb) s - step.

(gdb) si

(gdb) finish - return this function.

(gdb) u - until. skip loop.

(gdb) q - quit

+++

8 Examining the Stack

(gdb) bt

(gdb) bt f - `bt full`.

(gdb) thread apply all backtrace

(gdb) f 9

(gdb) i args

(gdb) i lo - local variables

+++

10 Examining Data

(gdb) p 3*i

(gdb) p/x 3*i

(gdb) p/s str

(gdb) p array[3]@12 - will print out values starting at array position 3 for 12 positions

(gdb) p/x (short[2])0x12345678 // 强制把一个整数当作一个数组来看.

$1 = {0x1234, 0x5678}

(gdb) p/x (short[])0x12345678 // 自动计算数组size.

$2 = {0x1234, 0x5678}

(gdb) x/s 0x20034 - examine memory, addr 0x20034, as a string

(gdb) po someObj

po命令与print命令也极为相似,只不过它只能对objc对象求值,并返回description函数的内容.如果po命令失败,你可以通过显式调用description函数来查看内容.

Note:No printf command. printf only is used in `commands`

Symbol可以用单引号括起来,以免GDB无法正确识别.例如:对于foo.c会识别成3个变量,所以要这样做:

*p 'foo.c'::x

whatis 命令可以显示某个变量的类型

ptype:比whatis的功能更强，他可以提供一个结构的定义

(gdb) whatis v

type = struct complex

(gdb) ptype v

type = struct complex {

double real;

double imag;

}

info types regexp - 注意，regexp是正则。

info functions regexp -

info var regexp -

info classes regexp -

info selectors regexp -

info address symbol - 仅仅显示地址,作用不大.

info symbol addr - 好像仅对全局变量,类定义,函数起作用.总之,作用似乎不大.

+++

17 Altering Execution

(gdb) p x=4

(gdb) p my_function () - calls a function

(gdb) call my_function () - same as p.call命令与print命令基本相同.唯一的差别是:如果返回值是void,则call不会显示任何内容,仅仅执行该函数,而print会打印该void,并将值保存到value history.对于有返回值的函数,则call于print的操作结果完全相同,包括执行函数,并在屏幕显示执行结果,同时将值保存到value history.

+++

设置GDB变量

(gdb) set $i = 0 -

(gdb) set $i++ - 注意++必须用set。

(gdb) p bar[$i++]->contents -但是在表达式里面的++就不用set了。

(gdb) show convenience - 显示所有gdb变量。

+++

Line

(gdb) l 23 - list to terminal screen 10 lines of current source

centered at line 23

(gdb) l fn.c:22 -

(gdb) l func -

(gdb) l - print 10 or more lines after lines last printed

+++汇编

(gdb) set disassembly-flavor intel

(gdb) disas mainFun

(gdb) show architecture - Show architecture of target.

(gdb) x/5i $pc - examine memory address.

(gdb) i r - registers

(gdb) p $eip。

+++其他

(gdb) show paths -程序路径。Show命令用于显示gdb的一些信息。

(gdb) shell - 在gdb中运行shell命令。

回车，是重复上一个命令

+++++

佳为好友 2012-12-26 09:53 发表评论

原：gdb打印NSArray里面的每个元素的内容

佳为好友 — Wed, 26 Dec 2012 01:53:00 GMT

创建：2012.10.19

一个NSArray里面有Item，Item有元素s1和s2

如果普通的po命令，则只能打印出Item的地址。

如果想的到Item的s1和s2的值，则需要：

(gdb) set $i = 0

(gdb) set $c = (int)[arr count]

(gdb) while ($i < $c)

>po [[arr objectAtIndex:$i] s1]

>po [[arr objectAtIndex:$i++] s2]

>end

(gdb)

如果不嫌手动麻烦，也可以

(gdb) set $i = 0

(gdb) po [[arr objectAtIndex:$i++] s1]

(gdb)

+++++

佳为好友 2012-12-26 09:53 发表评论

原：GDB的conditions的摘要

佳为好友 — Wed, 26 Dec 2012 01:52:00 GMT

创建:2012.10.12

转：http://sourceware.org/gdb/current/onlinedocs/gdb/Conditions.html#Conditions

conditions也可以在设定断点的时候就直接指定，在break后面加if，例如：

conditions也可以使用conditions命令来更改。

指定condition的方法

1）condition 断点序号 expression ：为一个断点设定condition

2）condition 断点序号：删除一个断点的condition

3）ignore 断点序号 count ：忽略前count次。

4）ignore 断点序号 0 ：重置了ignore。

如果一个断点既有condition又有ignore，那么condition将会被忽略，直到ignore的值都被消耗完才继续判断condition。

你可以自己实现一个既响应condition又响应ignore的方法，就是结合condition和gdb的convenience variable，例如，设定一个condition为“$foo-- <= 0”

+++++

佳为好友 2012-12-26 09:52 发表评论

原：GDB Command Lists摘要 -2

佳为好友 — Wed, 26 Dec 2012 01:51:00 GMT

创建：2012.10.12

修改：2012.10.12

转：http://sourceware.org/gdb/current/onlinedocs/gdb/Break-Commands.html#Break-Commands

GDB Command Lists

用法：

commands 1

silent

printf "x is %d\n",x

cont

end

如果要删除一个断点的command，只需要在commands后面直接跟end，例如

commands 1

end

如果commands后面没有跟任何数字，则默认是在为最后一个设定的断点设定commands，注意，不是你当前中断的断点。例如：

1）

break foo if x>0

commands

printf "x is %d\n",x

end

2）

(gdb) break

Breakpoint 3 at 0x9470d674

(gdb) commands

>x/s $ecx

>end

(gdb) c

comands里面可以放继续执行gdb的命令，如continue，step等。不过，这些命令之后的任何命令都会被忽略掉（因为gdb已经开始继续运行了）。

如果commands的第一个命令是silent，则该断点中断时，出现的一般提示将不会在出现。注意，silent必须是第一个命令。

也可以在command中改变变量的值，例如

commands 403

set x = y + 4

end

commands中，一般的打印的命令都将失效，只能使用echo，output和printf。一般只使用printf就足够了。

printf的例子：

printf "foo, bar-foo = 0x%x, 0x%x\n", foo, bar-foo

一些复杂的例子：

(gdb) b *0x9470d674

Breakpoint 1 at 0x9470d674

(gdb) commands

Type commands for when breakpoint 1 is hit, one per line.

End with a line saying just "end".

>call (char *)class_getName($eax)

>x/s $ecx

>end

(gdb) run

commands

set $id = *(long *)($esp+4)

set $sel = *(long *)($esp+8)

if(*(long *)($id+8) != 0)

printf "[%s %s]\n", *(long *)($id+8),$sel

continue

end

set $isx = *(long *)($id)

printf "[%s %s]\n", *(long *)($isx+8),$sel

continue

end

+++++

佳为好友 2012-12-26 09:51 发表评论

原：汇编MOV和LEA

佳为好友 — Wed, 26 Dec 2012 01:51:00 GMT

创建：2012.10.12

int v = 123;

int *p = &v;

int **pp = &p; // &&v

lea p v

int *p = &v;

move v p

int v = *p;

move v [pp] // pp是一个变量的地址，该变量存储了另外一个地址

int v = **pp

lea p [pp]

int *p = *pp; // p

move [p] v

int *p = v

+++++

佳为好友 2012-12-26 09:51 发表评论

原：GDB的数据断点和ObjC的@property

佳为好友 — Wed, 26 Dec 2012 01:50:00 GMT

创建：2012.10.05

OC的@property可以让编译器自动提供对应的成员变量，而不必再指定@synthesize quoteData=quoteData;

但是，当使用gdb的watch命令的时候，它却无法成功，例如：

(gdb) watch self.dataSource.quoteData

因为有@property生成的quoteData只是一个get函数，它返回的值是一个临时的指针，因此无法跟踪。

解决方法是再dataSource中创建一个quoteData的成员变量，例如：

@interface F7iPhoneQuoteViewControllerDataSource : NSObject<QuotesManagerDelegate>
{
Quote *quoteData;
}

然后，在调试时使用：
(gdb) watch self.dataSource->quoteData

这样就可以了。

＋＋＋＋＋

佳为好友 2012-12-26 09:50 发表评论

原：使用GDB调试某次NSNotification

佳为好友 — Wed, 26 Dec 2012 01:50:00 GMT

创建：2012.06.01

已知某个时间会发出一个NSNotification，但是不知道是哪个NSNotification。

直接设置[NSNotificationCenter postNotificationName:object:]和[NSNotificationCenter postNotificationName:object:userInfo:]会导致很多的中断，因此，使用一个断点命令，同时打印出NSNotification的参数内容，然后一次查找可能的Notification。

过程如下：

1,运行程序；

2,中断程序；

3,设置断点：

(gdb) b [NSNotificationCenter postNotificationName:object:]

Breakpoint 1 at 0x2068ad8

(gdb) b [NSNotificationCenter postNotificationName:object:userInfo:]

Breakpoint 2 at 0x205c147

4,设置断点的命令：

(gdb) commands 1

>po *(id *)($fp + 16)

>po *(id *)($fp + 20)

>end

(gdb) commands 2

>po *(id *)($fp + 16)

>po *(id *)($fp + 20)

>end

5,继续运行

(gdb) c

6,等待事件发生。

7,查看Log。

Continuing.

_UIApplicationDidBeginIgnoringInteractionEventsNotification

Continuing.

UIViewAnimationDidCommitNotification

UIViewAnimationState

Continuing.

UIViewAnimationDidCommitNotification

UIViewAnimationState

Continuing.

其中：po *(id *)($fp + 16)为函数第一个参数。

＋＋＋＋＋

佳为好友 2012-12-26 09:50 发表评论

原：检查内存泄露的思路

佳为好友 — Wed, 26 Dec 2012 01:50:00 GMT

创建：2011.10.10

首先，使用XCode的静态解析工具，尽量去掉内存泄露的地方。
然后，使用Leaks工具找到内存泄露的对象。记得选择Leaks，并去掉每10s的自动解析功能，要手动解析，因为这样运行起来会比较快。
按照先易后难的方法解决每个Leak，有时候你会发现，那些比较难的Leak，会随着简单的Leak的解决而消失。
结合Zombies来解决Leaks。

比较复杂的Leaks：
Leak发生在系统函数中。
随机的Leak。
只有真机才出现的Leak。无法使用Zombies。
程序太大了，导致无法使用Leaks程序解析。

＋＋＋＋＋

佳为好友 2012-12-26 09:50 发表评论

原：利用Leaks和Zombies检查内存泄露

佳为好友 — Wed, 26 Dec 2012 01:49:00 GMT

创建：2011.10.10
修改：2011.10.28

本文无效。Leaks可以直接查看retain和release的历史。

Leaks只能知道哪个类进行了泄露，以及它是在什么地方分配的。但是，却无法知道是在什么地方泄露的，也就是说无法知道全部的retain和release的历史。但是，Zombies却知道，因此可以结合两者。

方法如下：

用Leaks找到内存泄露的类。
找到该对象的分配地址。
利用TTT类延迟10s释放该对象，释放多次，确保一定Crash。
然后使用Zombies运行程序。
当程序因为TTT崩溃时，查看retain／release的历史。检查在什么地方两者不匹配了。

使用此方法普通的泄露问题都可以解决。

此外，TTT类是另一篇文章里面的类。用于结合Zombies类查看对象的retain和release的历史的。
＋＋＋＋＋

佳为好友 2012-12-26 09:49 发表评论

转：iPhone Crash Logs -3

佳为好友 — Wed, 26 Dec 2012 01:49:00 GMT

/Files/walkklookk/symbolicatecrash.txt

日期：2010.12.23
修改：2011.05.14
修改：2011.06.22

转：http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/

[2011.06.22自：我已经写了一个更加详细和介绍更多内幕的教程了。参见：原：使用Crash文件的步骤和原理]

【自：非常强大的工具和用法。可以直接通过crash 文件和对应的dSYM文件，得到crash所在的代码的行数。
在使用之前，有几个注意事项：
1，发布代码之前，从svn上重新下载一份代码，并单独保存到一个文件中。
这样，就可以生成独立的dSYM和源代码。不必和现有的代码冲突。
2，如果没有这样做。则在重新恢复现场的时候，要 update一份当时的代码。
3，保留dSYM。
另外，我没有在作者提到的路径下面找到 symbolicatecrash工具，于是，从网上找到了一份，并放到附件中了。
另外，我也没能copy到/usr/local /bin/下，所以我复制到/usr/bin/也一样可以。
】

iPhone Crash Logs

Sometimes programs crash. This annoys users and developers alike. Users are frustrated because they cannot use crashing software, developers are frustrated because they have to hunt bugs instead of doing something creative and rewarding. How do we communicate if an iPhone application crashes?

I’ll start with a disclaimer. I’m not sure whether the information provided in this post is covered by iPhone Developer Program NDA or not. If it is, the post will be removed. Secondly, this post is a result of googling, so I haven’t invented anything new here.

Working with crash logs typically involves certain interaction between developers and users, unless they are automagically sent to the developer. First of all, the user should get the crash log and send it to the developer, who should examine it, find the bug and fix it.

iPhone OS and Mac OS X are remarkably similar architectures. Both store crash logs to help identify crashing bugs. The difference between the two is how users retrieve them. On Mac OS X every user has unrestricted access to crash logs related to the applications she runs. The iPhone does not even have a file browser. What to do? iTunes comes to the rescue.

Whenever you synchronize your iPhone or iPod Touch, all the crash logs are transferred to your computer. Here are their locations:

Mac OS X : ~/Library/Logs/CrashReporter/MobileDevice/
Windows XP: C:\Documents and Settings\\Application Data\Apple computer\Logs\CrashReporter/<DEVICE_NAME>
Windows Vista: C:\Users\\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice/

The log file names start with application name and have the extension “crash”. They are just plain text files and can be sent by e-mail in original or zipped form, or even copy-pasted into your e-mail program.

The second part is trickier. Both Apple and common sense suggest that all AppStore binaries are shipped with stripped symbols. If you ever saw a crash log like this, read on:

Thread 0 Crashed: 0   libobjc.A.dylib           0x300c87ec 0x300bb000 + 55276 1   MobileLines               0x00006434 0x1000 + 21556 2   MobileLines               0x000064c2 0x1000 + 21698 3   UIKit                     0x30a740ac 0x30a54000 + 131244    4   UIKit                     0x30a66110 0x30a54000 + 74000 5   UIKit                     0x30a6565c 0x30a54000 + 71260 6   GraphicsServices          0x3169b0b4 0x31696000 + 20660 7   GraphicsServices          0x3169d818 0x31696000 + 30744    8   IOMobileFramebuffer       0x31f3e8f8 0x31f3d000 + 6392 9   com.apple.framework.IOKit 0x30f342b8 0x30f30000 + 17080 10  CoreFoundation            0x3025ced4 0x30229000 + 212692 11  CoreFoundation            0x3025bed6 0x30229000 + 208598    12  CoreFoundation            0x3025b584 0x30229000 + 206212 13  GraphicsServices          0x316998e4 0x31696000 + 14564 14  UIKit                     0x30a5e308 0x30a54000 + 41736 15  UIKit                     0x30a671dc 0x30a54000 + 78300    16  MobileLines               0x00002090 0x1000 + 4240 17  MobileLines               0x0000202c 0x1000 + 4140

In a nutshell, it contains function addresses and offsets instead of function names and line numbers. The structure is obvious, but, to be honest, I don’t know what“MobileLines 0×00006434 0×1000 + 21556″ is, even though I have all the source code. Thanks to Apple Developer Tools and to Craig Hockenberry who wrote about it, we have a perfect solution called symbolicatecrash.

I copied it to /usr/local/bin/ so that I can run it whenever I want without trying to remember its original location (you may prefer a symbolic link):
$ sudo cp /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash /usr/local/bin/

Running this script with the -h option provides the minimal help:

$ symbolicatecrash -h usage:

symbolicatecrash [-Ah] LOGFILE [SYMBOL_PATH ...]

Symbolicates a crashdump LOGFILE which may be "-" to refer
to stdin. By default, all heuristics will be employed
in an attempt to symbolicate all addresses. Additional
symbol files can be found under specified directories.

Options: -A Only symbolicate the application, not libraries -h Display this message -v Verbose

To add symbols to the crash log you need the dSYM file generated by the linker when you compiled your application for AppStore. In other words, when you build for AppStore you should keep the dSYM package in a safe place backed up by Time Machine. This is very important. You should keep a copy of the dSYM for each version of your application ever shipped. If you have the package, translating code offsets to function names with line numbers has never been easier:

$ symbolicatecrash report.crash MobileLines.app.dSYM > report-with-symbols.crash

Here is the result:

Thread 0 Crashed: 0   libobjc.A.dylib           0x300c87ec objc_msgSend + 20 1   MobileLines               0x00006434 -[BoardView setSelectedPiece:] (BoardView.m:321) 2   MobileLines               0x000064c2 -[BoardView touchesBegan:withEvent:] (BoardView.m:349)    3   UIKit                     0x30a740ac -[UIWindow sendEvent:] + 264 4   UIKit                     0x30a66110 -[UIApplication sendEvent:] + 248 5   UIKit                     0x30a6565c _UIApplicationHandleEvent + 4088    6   GraphicsServices          0x3169b0b4 PurpleEventCallback + 428 7   GraphicsServices          0x3169d818 HeartbeatVBLCallback + 152 8   IOMobileFramebuffer       0x31f3e8f8 IOMobileFramebufferNotifyFunc + 124    9   com.apple.framework.IOKit 0x30f342b8 IODispatchCalloutFromCFMessage + 304 10  CoreFoundation            0x3025ced4 __CFMachPortPerform + 72 11  CoreFoundation            0x3025bed6 CFRunLoopRunSpecific + 2364    12  CoreFoundation            0x3025b584 CFRunLoopRunInMode + 44 13  GraphicsServices          0x316998e4 GSEventRunModal + 268 14  UIKit                     0x30a5e308 -[UIApplication _run] + 404 15  UIKit                     0x30a671dc UIApplicationMain + 1064    16  MobileLines               0x00002090 main (main.m:16) 17  MobileLines               0x0000202c start + 44

Now, this is much better. Happy debugging!

＋＋＋＋＋

佳为好友 2012-12-26 09:49 发表评论

转：How to debug those random crashes in your Cocoa app －非常强悍的调试技巧

佳为好友 — Tue, 25 Dec 2012 02:04:00 GMT

日期：2011.06.07

[自：非常强悍的调试技巧。
iphone也可以用，但是有些地方不同了。选项和名字。]

转：http://www.corbinstreehouse.com/blog/2007/10/instruments-on- leopard-how-to-debug-those-random-crashes-in-your-cocoa-app/

Update: Sept 9, 2009: Mac OS 10.6 Snow Leopard now has this feature built into Instruments! In Xcode, choose “Run -> Run with Performance Tool -> Zombies”, and repeat your steps that cause the crash. Easy as pie. Read on if you don’t have Snow Leopard…

Mac OS 10.5 Leopard has a great new developer app called Instruments.

It can easily be used to debug those “random crashers” in your application caused by too many -release or -autorelease calls. Let’s see how.

If you want to follow along, download this project: CrashTestDummy.zip

Open it up in Xcode.

The nib has two outlets in it: a basic NSObject called testObject and button setup to invoke the following code:

- (IBAction)buttonCrashTestAction:(id)sender {

// We are going to autorelease the testObject too many times..

[testObject autorelease];

}

So, we will hit the button a few times and we should get a crash. Compile the app with the Debug target. Start Instruments, and select the Object Allocations template:

Hit the purple “i” next to the instruments to bring up the inspector for it, and be sure to check “Record reference counts”, as seen below:

Cool. Click “Launch Executable” and select “Choose Executable”, and find CrashTestDummy.app from the built directory.

While you have the Open Panel up, add the environment variable NSZombieEnabled and set it to YES (sort of an optional step):

Hit Open, if you haven’t already done so.

Hit “Record” in instruments, which will start the app, and click the “Crash Test” button a few times until the app crashes.

Alright! Fire up Console.app and look for a line like this:

The important part is the address, 0x150d40, in this case.

In Instruments, move the mouse to the right of “All Allocations” and a little triangle appears:

Click on it to see all the allocations.

In the lower right hand corner of instruments click on the magnifying glass in the NSSearchField and select “Address”:

Type in your address, and you should see all allocations at that address:

Now, why so many? Well, addresses are reused. Chances are, the last allocation is your object, and sure enough, it is, since we know we are over releasing an NSObject instance. Click on that item, and you’ll see the history for it. Scroll to the bottom to see just the history for that NSObject:

Now! You should be able to figure out which release probably shouldn’t be there. We know it is #19 from our demo, but sometimes it isn’t that easy to figure out. Select #19′s row and then click the little gray arrow to next to its address (or whatever yours is), and then click on this button at the bottom of instruments to show the stack trace / extended detail:

You can then see when that “bad release” happened. Click on the thumb below for a full size screen shot of it.

Ahh! Way cool. Of course, this was a simple and easy test case.

Happy debugging :)

corbin

＋＋＋＋＋

佳为好友 2012-12-25 10:04 发表评论

转：So you crashed in objc_msgSend()

佳为好友 — Tue, 25 Dec 2012 02:01:00 GMT

日期：2011.05.16

[自：对于objc_msgSend() 的情况介绍的很详细，可以用于调试。不过，用处不大。]

转：http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html

[objc explain]: So you crashed in objc_msgSend() (2008-09-22 02:02 PM)

So you crashed in objc_msgSend(). Now what?

Most likely, you sent a message to an already-freed object. Or maybe your pointer is perfectly correct, but someone else mangled the object's contents - perhaps a buffer overrun in a nearby allocation, or use of a dangling pointer that once pointed to the memory now occupied by your object. Occasionally objc_msgSend()crashes because a memory error smashed the runtime's own data structures, but usually the trouble is in the receiver object itself.

Whether you're in the debugger or looking at a crash log, you can recover more information about the crash than just the backtrace.

Receiver and selector registers

objc_msgSend() stores the receiver object and the selector in CPU registers while it works. These values can help diagnose the problem.

The register names differ based on architecture and the objc_msgSend() variant used. This list is correct for Mac OS X Leopard and will probably remain correct for Snow Leopard.

	`objc_msgSend` `objc_msgSend_fpret`		`objc_msgSend_stret`
	`receiver`	`SEL`	`receiver`	`SEL`
i386	eax*	ecx	eax*	ecx
x86_64	rdi	rsi	rsi	rdx
ppc	r3	r4	r4	r5
ppc64	r3	r4	r4	r5
arm	r0	r1	r1	r2

* i386 note: The receiver is in eax for most crashes, but not all. If you manage to get far into objc_msgSend() before falling over, then eax will have some other value.

Interpreting the receiver and invalid address

You can use the receiver's address and the invalid address that caused the crash to get some hints about the underlying problem. In a crash log, the receiver's address is in the Thread State using the register name in the table above, and the invalid address is listed at the top (usually something like KERN_PROTECTION_FAILURE at ). In the debugger console, the invalid address is printed when the program stops, and you can print the receiver's address using the register name in the table above.

    Program received signal EXC_BAD_ACCESS, Could not access memory.
    Reason: KERN_PROTECTION_FAILURE at address: 0x00000001
    0x00090ec4 in objc_msgSend ()
    (gdb) p/x $eax
     $1 = 0x1

My test program crashed at [(id)1 release]. In real crashes, these values are typically more interesting.

Usually, one of two things happens. The receiver address itself is bogus, and the invalid address is the same value (or 16 or 32 bytes away). Or the receiver address is reasonable, and the invalid address is the receiver's isa pointer. The latter is what usually happens if you try to use an already-deallocated object or someone else clobbered your valid object.

Look for special values like these in your crashes. Also look for nearby values; on some architectures, an invalid isa will cause a crash at isa+16 or isa+32 instead.

Not divisble by 16 - misaligned

malloc() returns 16-byte aligned blocks. If your receiver isn't 16-byte aligned, it probably never was a valid object pointer.

Top two and bottom two bits all set - malloc free list

After a block is freed, the memory allocator may write free list pointers into it. If you use a freed object after this, you'll see an isa pointer with the top two and bottom two bits all set.

All bits inverted - GC free list

Like the malloc free list case above, but caused by the garbage collector instead. In this case address looks bad, but ~address is more reasonable.

0xa1b1c1d3 - CF container

CoreFoundation containers use this value for deleted or empty items. Perhaps a freed object has been re-allocated as a container, or someone used a freed container that has been re-allocated as your object, or you read your pointer from a container that was simultaneously changed by some other thread and you don't have the right locks in place.

ASCII text

Perhaps a freed object has been re-allocated as a string, or someone used a freed string that has been re-allocated as your object, or some string operation has a buffer overrun. Use asciify to print these quickly in both endians. This one looks URL-related, for example:

% asciify 0x2e777777
###.www###
###www.###

Interrogating the selector

Compiler optimization means the call site pointed to by the second frame in the backtrace might not be the call that actually crashed. It's possible that call succeeded, and then that method made a tail call which was the one that crashed. Because of tail call optimization, the intermediate frame would be missing from the backtrace. We can use the selector register to determine what the real crashing call was.

A selector is a pointer to a unique C string. This may change in future OS versions, but for now it's handy for debugging. If you have crashed in a debugger, open the debugger console and run this, substituting the correct SEL register from the table above:

    (gdb) x/s $ecx
    0xa1029: "release"

Snow Leopard's crash reporter adds selector names to crash logs for you:

    Application Specific Information:
    objc_msgSend() selector name: release

Otherwise, retrieving the selector name from just a crash log is difficult and doesn't always work. Until you have Snow Leopard, cross your fingers and try this.

From the crash log's Thread State, find the SEL's value using the register name in the table above.
```
    ecx: 0x000a1029
```
From the crash log's Binary Images, find the image whose address range includes the SEL's value. This will often be either the application itself orlibobjc.A.dylib. If no image spans that address, give up.
0x8b000 - 0x106ff7 libobjc.A.dylib ??? (???) <9b5973b7fa88f9aab7885530c7b278dd> /usr/lib/libobjc.A.dylib
Find a copy of the image that matches the one in the crash log. Use the UUID to verify the match.
```
    % dwarfdump -u /usr/lib/libobjc.A.dylib
    UUID: 26650299-C6EA-B1C8-52D6-072AC874D400 (ppc) /usr/lib/libobjc.A.dylib
    UUID: 9B5973B7-FA88-F9AA-B788-5530C7B278DD (i386) /usr/lib/libobjc.A.dylib
     UUID: D2A4E8E1-3C1C-E0D9-2249-125B6DD621F8 (x86_64) /usr/lib/libobjc.A.dylib
```
This crash matches my installed libobjc.A.dylib for i386. If it's a system library, you may need the image from the OS version listed in the crash log. If it's your application, you did keep a copy of every version you shipped, right?
Calculate the SEL's offset into the image.
```
    0xa1029 - 0x8b000 = 0x16029
```

Print the C string in the image at that offset. Remember to specify the correct architecture.

    % otool -v -arch i386 -s __TEXT __cstring /usr/lib/libobjc.A.dylib | grep 16029
    00016029  release

＋＋＋＋＋

佳为好友 2012-12-25 10:01 发表评论

转：Manually symbolicating crash logs with gdb

佳为好友 — Tue, 25 Dec 2012 02:01:00 GMT

创建：10-12-30

转：http://www.picsoftware.ca/blog/?p=8

[自：简单步骤：
1，首先对比App的UUID，来确定Crash的版本和App版本是否符合；
2，进入到App和dSYM文件的目录；
3，运行/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp；
4，

set print asm-demangle on
5，

set print symbol-filename on
6，

p/a 0×00015c64
0×00015c64就是想要查询的位置。
]

Manually symbolicating crash logs with gdb

If you’ve ever downloaded a crash report from iTunes Connect for one of your apps there is a good chance that you had a hard time getting any useful information from it. The stack traces in these crash reports don’t contain the meaningful method and file names that would help you track down the bug, they only contain the hexadecimal addresses of the methods. According to this page as long as you have the proper .app and .dSYM files somewhere that Finder can find them Xcode’s Organizer should be able to translate these addresses to the source code method name and line number to which they refer. This is a process called symbolication. In my experience sometimes this works and sometimes it doesn’t.【自：有时候好用，有时候不好用。】 I have tried opening crash reports in the organizer and seen none or in some cases only a few of the symbols coming from my code being properly resolved . This post will describe a method to manually symbolicate these addresses when the Organizer doesn’t work.

As you can see from this screenshot this is a crash log that Xcode only symbolicated a few of the addresses that originated from my code in lines 6 and 7 of the stack trace. Lines 0-5 have not been symbolicated.

So let’s symbolicate these addresses manually. First we need to make sure we have the right .app and .dSYM files. The UUID in the crash log has to match the ones in our .app and .dSYM files. We can check this with a command line utility called dwarfdump.

Running dwarfdump with the –uuid option on our executable gives us this result:

pics‐imac:Downloads pic$ dwarfdump ‐‐uuid MyApp.app/MyApp     [自：注意，这里不是.app文件夹，而是在.app下的可执行文件]

UUID: E2D9D241‐37D3‐CE06‐7272‐653B813963E2 (armv6) MyApp.app/MyApp

Now we run the same command on our .dSYM file and get this result:

pics‐imac:Downloads pic$ dwarfdump ‐‐uuid MyApp.app.dSYM
UUID: E2D9D241‐37D3‐CE06‐7272‐653B813963E2 (armv6)
MyApp.app.dSYM/Contents/Resources/DWARF/MyApp

Good, they match, so we can now check if they are the same as the UUID in the crash log. This can be found in the Binary Images section of the crash log as you can see in this screenshot.

You’ll notice they aren’t in the same format (the one in the crash log doesn’t have the dashes) but that doesn’t matter, as long as the numbers are the same everything is ok.

Now we know we have the .app and .dSYM files that match our crash log so we can launch gdb and start symbolicating. Make sure to use the arm version of gdb which is typically found at:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin

pics-imac:Downloads pic$/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp

You may see some warnings about not being able to read symbols for a bunch of frameworks but this is ok. We use the ‘p/a’ command in gdb to symbolicate the addresses from our crash log. Let’s start with the first unsymbolicated address on line 5 of the stack trace.

5 MyApp 0x0002b0ee 0x0002b0ee

Type this ate the gdb prompt:

(gdb) p/a 0x0002b0ee

The result is:

$1 = 0x2b0ee <_ZN7MyAppBase5touchEP8_touch_ts+14>

We can probably figure out what method this address is referring to from that but it is still a little ugly. There must be a way to tell gdb to make it nicer for us. After a quick search I found this site that explains some gdb print settings:

http://www.delorie.com/gnu/docs/gdb/gdb_58.html

One that looks promising is:

set print asm-demangle on
Print C++ names in their source form rather than their mangled form, even in assembler code printouts such as instruction disassemblies. The default is off.

Let’s turn it on and see what happens.

(gdb) set print asm-demangle on (gdb) p/a 0x0002b0ee

And now the result is:

$2 = 0x2b0ee

This is much better, we can now see the class name, method name, parameters, and an offset. The only other thing I would like to see is the source code file name and line number just like a properly symbolicated crash log in the Organizer would show. After checking the website with the gdb print settings I found one that looks like it might do what I want:

set print symbol-filename on
Tell GDB to print the source file name and line number of a symbol in the symbolic form of an address.

Let’s try it.

(gdb) set print symbol-filename on (gdb) p/a 0x0002b0ee

This is the result we get:

$3 = 0x2b0ee /Users/pic/Dev/MyApp/Source/MyApp.cpp:307>

Perfect! So now we can check the rest of the addresses in the crash log to get the full stack trace and find out exactly where the crash occurred.

(gdb) p/a 0x0006840a
$4 = 0x6840a /Users/pic/Dev/MyApp/Source/widgets/Container.cpp:227>
(gdb) p/a 0x000400ac
$5 = 0x400ac 
/Users/pic/Dev/MyApp/Source/PuzzleView.cpp:135>
(gdb) p/a 0x0006840a
$6 = 0x6840a /Users/pic/Dev/MyApp/Source/widgets/Container.cpp:227>
(gdb) p/a 0x0002e216

$7 = 0x2e216 /Users/pic/Dev/MyApp/Source/widgets/Keyboard.cpp:333>
(gdb) p/a 0x0003aa9a
$8 = 0x3aa9a /Users/pic/Dev/MyApp/Source/Grid.cpp:730>

(gdb) q
pics-imac:Downloads pic$

Now we know the crash was at line 730 in Grid.cpp and we can go find the bug.

It would be nice if Xcode’s Organizer would just work all the time, but it has been my experience that sometimes for whatever reason it just doesn’t, even if you have the right .app and .dSYM files. In those cases I find this method to be very useful.

Happy debugging!

＋＋＋＋＋

佳为好友 2012-12-25 10:01 发表评论

转：非常好的检测内存问题的文章

佳为好友 — Tue, 25 Dec 2012 02:00:00 GMT

创建：10-11-18

转：http://gabriel.github.com/gh-unit/_env_variables.html

Environment Variables

GHUnit Environment Variables

Go into the "Get Info" contextual menu of your (Tests) executable (inside the "Executables" group in the left panel of XCode). Then go in the "Arguments" tab. You can add the following environment variables:

 GHUNIT_CLI - Default NO; Runs tests on the command line (see Debugger Console, Cmd-Shift-R)
 GHUNIT_RERAISE - Default NO; If an exception is encountered it re-raises it allowing you to crash into the debugger

 GHUNIT_AUTORUN - Default NO; If YES, tests will start automatically
 GHUNIT_AUTOEXIT - Default NO; If YES, will exit upon test completion (no matter what); For command line MacOSX testing

Test Environment Variables (Recommended)

 Environment Variable:                 Default:  Set to:
 NSDebugEnabled                           NO       YES
 NSZombieEnabled                          NO       YES

 NSDeallocateZombies                      NO       NO (or YES)
 NSHangOnUncaughtException                NO       YES
 NSAutoreleaseFreedObjectCheckEnabled     NO       YES

If Using NSDeallocateZombies=NO, then all objects will leak so be sure to turn it off when debugging memory leaks.

For more info on these varaiables see NSDebug.h (http://theshadow.uw.hu/iPhoneSDKdoc/Foundation.framework/NSDebug.h.html)

For malloc debugging:

 MallocStackLogging
 MallocStackLoggingNoCompact
 MallocScribble
 MallocPreScribble
 MallocGuardEdges
 MallocDoNotProtectPrelude
 MallocDoNotProtectPostlude

 MallocCheckHeapStart
 MallocCheckHeapEach

If you see a message like:

 2009-10-15 13:02:24.746 Tests[38615:40b] *** -[Foo class]: message sent to deallocated instance 0x1c8e680

Re-run (in gdb) with MallocStackLogging=YES (or MallocStackLoggingNoCompact=YES), then if you run under gdb:

 (gdb) shell malloc_history 38615 0x1c8e680
 
 ALLOC 0x1a9ad10-0x1a9ad6f [size=96]: thread_a024a500 |start | main | UIApplicationMain | GSEventRun | GSEventRunModal | CFRunLoopRunInMode | CFRunLoopRunSpecific | __NSThreadPerformPerform | -[GHTestGroup _run:] | -[GHTest run] | +[GHTesting runTest:selector:withObject:exception:interval:] | -[Foo foo] | +[NSObject alloc] | +[NSObject allocWithZone:] | _internal_class_createInstance | _internal_class_createInstanceFromZone | calloc | malloc_zone_calloc

Somewhere between runTest and NSObject alloc there may be an object that wasn't retained.

Also using MallocScribble=YES causes the malloc library to overwrite freed memory with a well-known value (0x55), and occasionally checks freed malloc blocks to make sure the memory has not been over-written overwritten written since it was cleared.

For more info on these variables see MallocDebug (http://developer.apple.com/mac/library/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html)

For more info on malloc_history see malloc_history (http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/malloc_history.1.html)

＋＋＋＋＋

佳为好友 2012-12-25 10:00 发表评论

转：NSDebug.h －Cocoa的用于调试的环境变量

佳为好友 — Tue, 25 Dec 2012 01:59:00 GMT

创建：10-11-18

转：http://theshadow.uw.hu/iPhoneSDKdoc/Foundation.framework/NSDebug.h.html

Foundation/NSDebug.h

iPhone.SDK
by hackstock

/*	NSDebug.h
Copyright (c) 1994-2005, Apple, Inc. All rights reserved.
*/

/**************************************************************************
WARNING: Unsupported API.

This module contains material that is only partially supported -- if
at all. Do not depend on the existance of any of these symbols in your
code in future releases of this software. Certainly, do not depend on
the symbols in this header in production code. The format of any data
produced by the functions in this header may also change at any time.

However, it should be noted that the features (but not necessarily the
exact implementation) in this file have been found to be generally useful,
and in some cases invaluable, and are not likely to go away anytime soon.
**************************************************************************/

#import <Foundation/NSObject.h>
#import <Foundation/NSAutoreleasePool.h>
#import <Foundation/NSDate.h>
#import <Foundation/NSPort.h>

/* The environment component of this API

The boolean- and integer-valued variables declared in this header,
plus some values set by methods, read starting values from the
process's environment at process startup. This is mostly a benefit
if you need to initialize these variables to some non-default value
before your program's main() routine gets control, but it also
allows you to change the value without modifying your program's
source. (Variables can be set and methods called around specific
areas within a program, too, of course.)

The initialization from the environment happens very early, but may
not have happened yet at the time of a +load method statically linked
into an application (as opposed to one in a dynamically loaded module). 
But as noted in the "Foundation Release Notes", +load methods that are
statically linked into an application are tricky to use and are not
recommended.

Here is a table of the variables/values initialized from the environment
at startup. Some of these just set variables, others call methods to
set the values.

NAME OF ENV. VARIABLE	 DEFAULT	SET TO...
NSDebugEnabled	 NO	"YES"
NSZombieEnabled	 NO	"YES"
NSDeallocateZombies	 NO	"YES"
NSHangOnUncaughtException	 NO	"YES"

NSEnableAutoreleasePool	 YES	"NO"
NSAutoreleaseFreedObjectCheckEnabled	 NO	"YES"
NSAutoreleaseHighWaterMark	 0	non-negative integer
NSAutoreleaseHighWaterResolution	 0	non-negative integer

*/

/****************	General	 ****************/

FOUNDATION_EXPORT BOOL NSDebugEnabled;
// General-purpose global boolean. Applications and frameworks
// may choose to do some extra checking, or use different
// algorithms, or log informational messages, or whatever, if
// this variable is true (ex: if (NSDebugEnabled) { ... }).

FOUNDATION_EXPORT BOOL NSZombieEnabled;
// Enable object zombies. When an object is deallocated, its isa
// pointer is modified to be that of a "zombie" class (whether or
// not the storage is then freed can be controlled by the
// NSDeallocateZombies variable). Messages sent to the zombie
// object cause logged messages and can be broken on in a debugger.
// The default is NO.

FOUNDATION_EXPORT BOOL NSDeallocateZombies;
// Determines whether the storage of objects that have been
// "zombified" is then freed or not. The default value (NO)
// is most suitable for debugging messages sent to zombie
// objects. And since the memory is never freed, storage
// allocated to an object will never be reused, either (which
// is sometimes useful otherwise).

FOUNDATION_EXPORT BOOL NSHangOnUncaughtException;
// If set to YES, causes the process to hang after logging the
// "*** Uncaught exception:" message. A backtrace can be gotten
// from the process with the 'sample' utility, or the process can
// be attached to with a debugger. The default is NO.

FOUNDATION_EXPORT BOOL NSIsFreedObject(id anObject);
// Returns YES if the value passed as the parameter is a pointer
// to a freed object. Note that memory allocation packages will
// eventually reuse freed memory blocks to satisfy a request.
// NSZombieEnabled and NSDeallocateZombies can be used to prevent
// reuse of allocated objects.

/****************	Stack processing	****************/

FOUNDATION_EXPORT void *NSFrameAddress(unsigned frame);
FOUNDATION_EXPORT void *NSReturnAddress(unsigned frame);
// Returns the value of the frame pointer or return address,
// respectively, of the specified frame. Frames are numbered
// sequentially, with the "current" frame being zero, the
// previous frame being 1, etc. The current frame is the
// frame in which either of these functions is called. For
// example, NSReturnAddress(0) returns an address near where
// this function was called, NSReturnAddress(1) returns the
// address to which control will return when current frame
// exits, etc. If the requested frame does not exist, then
// NULL is returned. The behavior of these functions is
// undefined in the presence of code which has been compiled
// without frame pointers.

FOUNDATION_EXPORT unsigned NSCountFrames(void);
// Returns the number of call frames on the stack. The behavior
// of this functions is undefined in the presence of code which
// has been compiled without frame pointers.

/****************	Autorelease pool debugging	****************/

// Functions used as interesting breakpoints in a debugger
FOUNDATION_EXPORT void _NSAutoreleaseNoPool(void *object);
// Called to log the "Object X of class Y autoreleased with no
// pool in place - just leaking" message.

FOUNDATION_EXPORT void _NSAutoreleaseFreedObject(void *freedObject);
// Called when a previously freed object would be released
// by an autorelease pool. See +enableFreedObjectCheck: below.

FOUNDATION_EXPORT void _NSAutoreleaseHighWaterLog(unsigned int count);
// Called whenever a high water mark is reached by a pool.
// See +setPoolCountHighWaterMark: below.

@interface NSAutoreleasePool (NSAutoreleasePoolDebugging)

+ (void)enableRelease:(BOOL)enable;
// Enables or disables autorelease pools; that is, whether or
// not the autorelease pools send the -release message to their
// objects when each pool is released. This message affects only
// the pools of the autorelease pool stack of the current thread
// (and any future pools in that thread). The "default default"
// value can be set in the initial environment when a program
// is launched with the NSEnableAutoreleasePool environment
// variable (see notes at the top of this file) -- as thread
// pool-stacks are created, they take their initial enabled
// state from that environment variable.

+ (void)showPools;
// Displays to stderr the state of the current thread's
// autorelease pool stack.

+ (void)resetTotalAutoreleasedObjects;
+ (unsigned)totalAutoreleasedObjects;
// Returns the number of objects autoreleased (in ALL threads,
// currently) since the counter was last reset to zero with
// +resetTotalAutoreleasedObjects.

+ (void)enableFreedObjectCheck:(BOOL)enable;
// Enables or disables freed-object checking for the pool stack
// of the current thread (and any future pools in that thread).
// When enabled, an autorelease pool will call the function
// _NSAutoreleaseFreedObject() when it is about to attempt to
// release an object that the runtime has marked as freed (and
// then it doesn't attempt to send -release to the freed storage).
// The pointer to the freed storage is passed to that function.
// The "default default" value can be set in the initial
// environment when a program is launched with the
// NSAutoreleaseFreedObjectCheckEnabled environment variable
// (see notes at the top of this file) -- as thread pool-stacks
// are created, they take their initial freed-object-check state
// from that environment variable.

+ (unsigned int)autoreleasedObjectCount;
// Returns the total number of autoreleased objects in all pools
// in the current thread's pool stack.

+ (unsigned int)topAutoreleasePoolCount;
// Returns the number of autoreleased objects in top pool of
// the current thread's pool stack.

+ (unsigned int)poolCountHighWaterMark;
+ (void)setPoolCountHighWaterMark:(unsigned int)count;
// Sets the pool count high water mark for the pool stack of
// the current thread (and any future pools in that thread). When
// 'count' objects have accumulated in the top autorelease pool,
// the pool will call _NSAutoreleaseHighWaterLog(), which
// generates a message to stderr. The number of objects in the
// top pool is passed as the parameter to that function. The
// default high water mark is 0, which disables pool count
// monitoring. The "default default" value can be set in the
// initial environment when a program is launched with the
// NSAutoreleaseHighWaterMark environment variable (see notes at
// the top of this file) -- as thread pool-stacks are created,
// they take their initial high water mark value from that
// environment variable. See also +setPoolCountHighWaterResolution:.

+ (unsigned int)poolCountHighWaterResolution;
+ (void)setPoolCountHighWaterResolution:(unsigned int)res;
// Sets the pool count high water resolution for the pool stack of
// the current thread (and any future pools in that thread). A
// call to _NSAutoreleaseHighWaterLog() is generated every multiple
// of 'res' objects above the high water mark. If 'res' is zero
// (the default), only one call to _NSAutoreleaseHighWaterLog() is
// made, when the high water mark is reached. The "default default"
// value can be set in the initial environment when a program is
// launched with the NSAutoreleaseHighWaterResolution environment
// variable (see notes at the top of this file) -- as thread
// pool-stacks are created, they take their initial high water
// resolution value from that environment variable. See also
// +setPoolCountHighWaterMark:.

@end

/****************	Allocation statistics	****************/

// The statistics-keeping facilities generate output on various types of
// events. Currently, output logs can be generated for use of the zone
// allocation functions (NSZoneMalloc(), etc.), and allocation and
// deallocation of objects (and other types of lifetime-related events).

// This boolean is obsolete and unused
FOUNDATION_EXPORT BOOL NSKeepAllocationStatistics;

// Object allocation event types
#define NSObjectAutoreleasedEvent	 3
#define NSObjectExtraRefIncrementedEvent	4
#define NSObjectExtraRefDecrementedEvent	5
#define NSObjectInternalRefIncrementedEvent	6
#define NSObjectInternalRefDecrementedEvent	7


FOUNDATION_EXPORT void NSRecordAllocationEvent(int eventType, ...);
// Notes an object or zone allocation event and various other
// statistics, such as the time and current thread. The additional
// arguments to be passed to this function vary by the type of
// event. The behavior is undefined (and likely catastrophic) if
// the correct arguments for 'eventType' are not provided.
//
// The parameter prototypes for each event type are shown below.
// NSRecordAllocationEvent(NSObjectAutoreleasedEvent, curObj)
// NSRecordAllocationEvent(NSObjectExtraRefIncrementedEvent, curObj)
// NSRecordAllocationEvent(NSObjectExtraRefDecrementedEvent, curObj)
// NSRecordAllocationEvent(NSObjectInternalRefIncrementedEvent, curObj)
// NSRecordAllocationEvent(NSObjectInternalRefDecrementedEvent, curObj)
//
// Only the Foundation should have reason to use many of these.
// Do not call NSRecordAllocationEvent(NSZoneMallocEvent, ...)
// after NSZoneMalloc(), for example, in your own code because
// NSZoneMalloc() has already done this for you. The only common
// use of this function should be with these two events:
//	NSObjectInternalRefIncrementedEvent
//	NSObjectInternalRefDecrementedEvent
// when a class overrides -retain and -release to do its own
// reference counting.
//

＋＋＋＋＋

佳为好友 2012-12-25 09:59 发表评论

转：GDB和ObjC结合的高级技巧

佳为好友 — Tue, 25 Dec 2012 01:59:00 GMT

创建：10-11-12

转：http://support.apple.com/kb/TA45906?viewlocale=en_US

Advanced Debugging Techniques

Backtraces

Gdb provides a set of commands that allow you to examine the state of your application. Use the backtrace command (bt) to find out where control has come from, based on a list of stack frames. Use the frame command (f) to choose which of those stack frames is selected. The info frame, info locals, and info args commands provide you with more information about the chosen frame. Remember that gdb's command line interpreter can evaluate any C or Objective-C expression, so when your application is stopped in gdb, you can examine and set variables of your program, make function calls, send messages to objects, and so on.

Backtrace output looks like this:

(gdb) bt
#0 -[MovieMgr fetchMovies] (self=0x439750, _cmd=0x402127) at MovieMgr.m:28
#1 0x401030 in -[MovieMgr init] (self=0x439750, _cmd=0x310255d3)
at MovieMgr.m:12
#2 0x320434c0 in +[NSObject new] ()
#3 0x31017842 in objc_msgSendv ()
#4 0x320410d5 in -[NSInvocation invoke] ()
#5 0x540b4134 in NMSPerformSelector ()
#6 0x540bf01e in -[WOObjCExpression evaluateInScope:debugger:] ()
#7 0x540bb575 in -[WOBinaryExpression evaluateInScope:debugger:] ()
#8 0x540bc8d5 in -[WOExpressionStatement executeInScope:debugger:] ()
#9 0x540c27b0 in -[WOStatements executeInScope:debugger:] ()
#10 0x540bc6a7 in -[WOCompoundStatement executeInScope:debugger:] ()
#11 0x540bd45f in -[WOMethod executeInParentScope:debugger:forSelf:arguments:]
()
#12 0x540be5a5 in -[WOModule evaluateMethodNamed:forSelf:count:arguments:inScope
:debugger:] ()
#13 0x540b7289 in _NMSGenericMethod ()
#14 0x540b72dd in -[_NMSScriptedClassShadow _genericVararg:] ()
#15 0x4201d5ad in -[WOComponent(WOComponentPrivate) _initWithName:] ()
#16 0x4201e7bb in -[WOComponentDefinition(WOComponentGeneration) componentInstan
ce] ()
#17 0x42018a5f in -[WOApplication(WOPageManagement) pageWithName:] ()
#18 0x4201932f in -[WOApplication(WORequestHandlingInternals) _handleRequestInPr
eparedSession] ()
#19 0x42019277 in -[WOApplication(WORequestHandlingInternals) _handleRequestInPr
eparedApplication] ()
#20 0x42019915 in -[WOApplication(WORequestHandling) handleRequest:] ()
#21 0x4202a0c5 in -[WODefaultAdaptor handleConnection:] ()
#22 0x3203946f in _postNotification ()
#23 0x32039d6a in -[NSNotificationCenter postNotificationName:object:userInfo:]
()
#24 0x320604ad in -[NSConcreteFileHandle handleMachMessage:] ()
#25 0x3206f0c6 in -[NSRunLoop acceptInputForMode:beforeDate:] ()
#26 0x3206f268 in -[NSRunLoop runMode:beforeDate:] ()
#27 0x42018d75 in -[WOApplication(WORunning) run] ()
#28 0x4012d6 in main (argc=4, argv=0x436430) at main.m:183
#29 0x40144c in mainCRTStartup ()
(gdb)

You can then inspect the frames.

(gdb) f 12
#12 0x540be5a5 in -[WOModule evaluateMethodNamed:forSelf:count:arguments:inScope
:debugger:] ()
(gdb)

If you have the symbols, you can use info args to print the function's arguments and info locals to print the local variables:

(gdb) info args
self = (MovieMgr *) 0x439750
_cmd = (struct objc_selector *) 0x402127
(gdb) info locals
self = (MovieMgr *) 0x439750
fetchSpec = (EOFetchSpecification *) 0x448a80
(gdb)

If you do not have the symbols, you can still get to some of the argument information by using the frame pointer and offsets. (These offsets vary based on system architecture.)

p *(id *)($fp + 8) - prints the receiver of the message (often the same as self)
p *(SEL *)($fp + 12) - prints the selector (the method that was called)
p *(id *)($fp + 16) - prints argument 1
p *(id *)($fp + 20) - prints argument 2
p *(id *)($fp + 24) - prints argument 3

(gdb) f 12
#12 0x540be5a5 in -[WOModule evaluateMethodNamed:forSelf:count:arguments:inScope
:debugger:] ()
(gdb) p *(id *)($fp + 8)
$4 = (WOModule *) 0x43ab70
(gdb) p *(id *)($fp + 16)
$5 = (NSInlineCString *) 0x428ff0
(gdb) po $5
init
(gdb) p *(id *)($fp + 20)
$6 = (WOScriptedClass(/WebObjects/Projects/batch.woa/Main.wo/Main) *) 0x432ea0
(gdb)

For convenience, you may want to create user-defined commands for these offsets in your .gdbinit file.

＋＋＋＋＋

佳为好友 2012-12-25 09:59 发表评论

转：很强大的介绍ObjC的内部知识，用于调试

佳为好友 — Tue, 25 Dec 2012 01:58:00 GMT

创建：10-11-12

转：http://www.phrack.org/issues.html?issue=66&id=4#article

The Objective-C Runtime:  Understanding and Abusing

＋＋＋＋＋

佳为好友 2012-12-25 09:58 发表评论

转：调试教程 – 使用UIRecorder Instrument将测试自动化

佳为好友 — Tue, 25 Dec 2012 01:57:00 GMT

创建：10-11-3

调试教程 – 使用UIRecorder Instrument将测试自动化

于 10-7-18 通过 iPhoneGeek 爱疯极客作者：bagusflyer

（注：这是我以前收集的一篇文章，找不到出处了，稍作修改在此发布）

如果你发现程序的bug，但每次进行测试都需要许多步骤才能重现问题，那么本教程适合你。通常，测试和调试是非常繁琐的事情，iPhone程序的开发尤其如此。

比如说，你有个程序需要经过5个步骤才能到达另一个view。如果你有一个bug发生在这个需要5步之多的view上，通常情况下调试的步骤如下：

运行程序
触击 view 1
触击view 2
触击 view 3
触击 view 4
触击 view 5
(程序崩溃)
修改代码
重复以上步骤

如你所见，这是多么痛苦的事情啊。 Kendall Gelner 在 360iDev 上有关使用Instruments 和 XCode进行调试的若干提示的演讲中，对我而言最为有用的就是将测试自动化。我演示一下应该怎么做:

1. 打开希望测试/调试的程序

2. 在模拟器中运行

3. 打开Instrument – 位于 /Developer/Applications/Instruments

4. 选择 UIRecorder 并按Choose - 你将看到下面窗口

5. 然后需要将此工具与iPhone模拟器进程链接。按下下拉菜单选择 Default Target -> Attach to Process -> iPhone Simulator.

6. 再按下 Drive & Record 并在模拟器中完成测试所需的所有步骤。至此，UI Recorder记录下了你的一举一动。完成时，按下Stop按钮。 注意： 在完成记录后请不要移动模拟器，因为这有可能会使弄乱整个处理过程。

7. 修改你的代码…

8. 按下 Drive & Record 按钮亲眼目睹一下有什么神奇的事情发生吧。测试自动进行了！你应该看到它自动模拟了你刚才进行的所有动作。

+++++

佳为好友 2012-12-25 09:57 发表评论

原:内存泄露问题经验

佳为好友 — Tue, 25 Dec 2012 01:55:00 GMT

创建：10-9-28

内存泄露问题:

*所有成员变量需要在程序中,多次赋值的,也就是说不仅仅是在初始化函数分配一次的,则一定要使用访问变量,否则容易引起内存的释放等问题.

*数组释放时异常,发现前几个元素都是0x0.注意,这个时候并不是因为数组因为有0x0的元素而导致的异常,而是因为在释放到0x0之后的元素时,发生了异常,很可能是外部将数组的元素释放了.至于有0x0的原因,是因为数组在依次释放,每次释放了一个元素之后,都会置为0x0.所以,显示0x0的元素,其实是正确释放了的元素.
修改方法是:查找数组的对象,是否正确释放了,有些时候,可能需要使用访问函数来进行成员变量的存储和释放,而不是直接操作成员变量.

*[alert show]会提示内存泄露.因为,alert不会在当前页面显示.它会被加入到系统的资源中,等待下次event到达之后,才会显示出来,因此,系统会在你show之后,自动retain它,然后在它显示之后,在release它.总而言之,你可以忽略它的泄露.
参见:http://stackoverflow.com/questions/2862335/uialertview-show-causing-a-memory-leak

*访问函数的内存泄露.如果某个变量有访问函数,则在程序中someVar = xxx会导致内存泄露,而[someVar release],则会导致异常退出.
方法是:
1,先使用@pro ,搜索所有的访问变量.然后全选,粘贴到某个文本文件中.
2,然后针对每个访问变量,搜索 [^.]sessionid[ ]*= 正则表达式来搜索所有someVar = xxx
3,然后针对每个访问变量,搜索 name[ ]*release 查看是否有除了在dealloc之外的删除,需要修正为self.xxx = nil;

+++++

佳为好友 2012-12-25 09:55 发表评论

转:深入理解ObjectiveC Part3

佳为好友 — Tue, 25 Dec 2012 01:54:00 GMT

摘要: 创建：10-9-25转:http://www.phrack.org/issues.html?issue=66&id=4#article--[ 5 - Exploiting Objective-C ApplicationsHopefully at this stage you're fairly familiar with the Objective-Cruntime. In this se... 阅读全文

佳为好友 2012-12-25 09:54 发表评论

C++博客-佳为好友-随笔分类-Debug-GDB

原：查看retain和release的历史记录

转：Enabling Remote Debugging via Private APIs in Mobile Safari

Enabling Remote Debugging via Private APIs in Mobile Safari

Enabling remote debugging in a UIWebView

Enabling remote debugging in Mobile Safari

Summing Up

原:gdb与时间戳

原:gdb

原：使用Crash文件的步骤和原理 -3

原：gdb高级技巧 -2

原：gdb user command file

原：gdb与dateWithTimeIntervalSince1970的bug

转：Inspecting Obj-C parameters in gdb -好

arm (before prolog)

ppc/ppc64

i386 (before prolog)

i386 (after prolog)

x86_64

原：检查内存泄露的思路 --2

创建：2011.10.10

原：常用GDB命令

原：gdb打印NSArray里面的每个元素的内容

原：GDB的conditions的摘要

原：GDB Command Lists摘要 -2

原：汇编MOV和LEA

原：GDB的数据断点和ObjC的@property

原：使用GDB调试某次NSNotification

原：检查内存泄露的思路

原：利用Leaks和Zombies检查内存泄露

转：iPhone Crash Logs -3

iPhone Crash Logs

转：How to debug those random crashes in your Cocoa app －非常强悍的调试技巧

转：So you crashed in objc_msgSend()

Receiver and selector registers

Interpreting the receiver and invalid address

Interrogating the selector

转：Manually symbolicating crash logs with gdb

Manually symbolicating crash logs with gdb

转：非常好的检测内存问题的文章

Environment Variables

GHUnit Environment Variables

Test Environment Variables (Recommended)

转：NSDebug.h －Cocoa的用于调试的环境变量

Foundation/NSDebug.h

转：GDB和ObjC结合的高级技巧

转：很强大的介绍ObjC的内部知识，用于调试

转：调试教程 – 使用UIRecorder Instrument将测试自动化

调试教程 – 使用UIRecorder Instrument将测试自动化

原:内存泄露问题经验

转:深入理解ObjectiveC Part3

Enabling remote debugging in a `UIWebView`