1、ARC中，對於調用私有函數調用中，返回值是void 或者參數本身是基本類型的，如果使用了id，因為ARC中會對參數和返回值進行retain,所以都會產生objc_retain的crash。 delloc函數是異步的：當對對象調用release的時候，即使該對象的retaincount = 0, 該對象的delloc函數也不是同步調用的。 例子：UIWebViewWk的destory函數的原因。 2、通用的情景是：觀察者使用的時候。 A->B->C A做為B的觀察者向下傳遞，B中的C會回調到A中方法。 傳統的A的delloc方法中銷毀B，B的delloc方法中銷毀C。在OC中由於 對象release之後，delloc方法是異步調用的，A delloc之後，B的retainCount = 0,但是當B的delloc函數還沒有 調用的時候，C發生回調，就會因為A的野指針crash。 這個時候就要實現B的destory方法來銷毀C。 這個destory方法在A的delloc方法中進行調用。這樣就保證了A delloc的時候C也delloc了。 3、docmentView上面加入手勢，網頁內容發生改變，如頁內的視頻跳轉之後，手勢發生crash. 4、panGesture手勢沒有調用touchMove，而初始化的代碼放在了touchMove中，導致變量沒有初始化，成為了野指針 5、屬性對象沒有retain，delloc的時候crash.

以下是更改的具體案例：

7、crash發生在C代碼中，很難追蹤到棧:bilsonzhou 3.0以前

0 libsystem_kernel.dylib 0x3432132c __pthread_kill (in libsystem_kernel.dylib) 8

1 libsystem_c.dylib 0x32e1829e abort (in libsystem_c.dylib) 94

2 libc abi.dylib 0x37589f6a abort_message (in libc abi.dylib) 46

3 libc abi.dylib 0x3758734c _ZL17default_terminatev (in libc abi.dylib) 24

4 libobjc.A.dylib 0x3692b36e _objc_terminate (in libobjc.A.dylib) 170

5 libc abi.dylib 0x375873c4 _ZL19safe_handler_callerPFvvE (in libc abi.dylib) 76

6 libc abi.dylib 0x37587450 operator delete(void*) (in libc abi.dylib) 0

7 libc abi.dylib 0x37588824 __cxa_current_exception_type (in libc abi.dylib) 0

8 libobjc.A.dylib 0x3692b2a8 objc_exception_rethrow (in libobjc.A.dylib) 12

9 CoreFoundation 0x35d6450c CFRunLoopRunSpecific (in CoreFoundation) 404

10 CoreFoundation 0x35d6436c CFRunLoopRunInMode (in CoreFoundation) 104

11 GraphicsServices 0x322e8438 GSEventRunModal (in GraphicsServices) 136

12 UIKit 0x3634ccd4 UIApplicationMain (in UIKit) 1080

13 MttHD 0x0000377e main (in MttHD) (main.m:15)

這個棧已經存在很長時間了，根本的Crash原因是對dictionary插入了nil對象。

為什麼棧變得這麼丑，找不到掛的地方？

因為這句代碼寫在了C代碼中：

void appScoreDataManager_Init(); //初始化評分管理信息

// whetherScoredFlag

NSNumber *numberObject = [g_AppScoreDataManager objectForKey:WHEHTER_SCORED_FLAG];

if (nil == numberObject)

{

[g_AppScoreDataManager setObject:MTTWhetherScoredFlag forKey:WHEHTER_SCORED_FLAG];

}

// APP_USED_COUNT

numberObject = [g_AppScoreDataManager objectForKey:APP_USED_COUNT];

if (nil == numberObject)

{

[g_AppScoreDataManager setObject:MTTAppUsedCount forKey:APP_USED_COUNT];

}

由於if語句中的代碼很難被執行，所以一直沒有發現。這個地方如果MTTWhetherScoredFlag不是等於0的話，會產生一個警告，

我們將warning作為error之後，這個地方就會編譯不通過，而恰恰這個地方MTTWhetherScoredFlag = 0。被當成了一個nil對象，

所以不會產生warning導致編譯不通過。

8、釋放一個autorelease對象：bilsonzhou 3.0以前

#0 0x3374ec98 in objc_msgSend ()

#1 0x3702bc36 in CFGetRetainCount ()

#2 0x34dc9c0e in CA::release_root_if_unused ()

#3 0x34dc9bba in x_hash_table_remove_if ()

#4 0x34da8f9c in CA::Transaction::commit ()

#5 0x34da2054 in CA::Transaction::observer_callback ()

#6 0x3706aa34 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()

#7 0x3706c464 in __CFRunLoopDoObservers ()

#8 0x3706d75a in __CFRunLoopRun ()

#9 0x36ffdec2 in CFRunLoopRunSpecific ()

#10 0x36ffddca in CFRunLoopRunInMode ()

#11 0x3195641e in GSEventRunModal ()

#12 0x319564ca in GSEventRun ()

#13 0x30ff5d68 in -[UIApplication _run] ()

#14 0x30ff3806 in UIApplicationMain ()

#15 0x00003ede in main (argc=1, argv=0x2fdff880)

at /Users/bilsonzhou/Desktop/QQBrowserIPAD/src/MttHDBrowser_iPad/MttHD/MttHD/main.m:15

該bug在5.0以上系統很難重現，在4.3.3系統上面隨機出現；

從這個棧看，沒有我們的代碼，也是鳥都看不出一個。

這是離線閱讀引進的bug，由於時間較長，相關同事也離職，查找原因時花了較長時間。

通過4.3真機調試時發現了如下系統日志：

modifying layer that is being finalized - 0xd332410

基本上鎖定為某個view進行了重復釋放，通過對離線閱讀中釋放的對象一一排查，

最後鎖定為：

m_btnDel = [UIButton buttonWithType:UIButtonTypeCustom];

在delloc中

[m_btnDel release];

這種crash雖然原因很簡單，但是由於隨機性和crash棧的信息有限，查找的難度很大。

9、內存被寫壞導致隨機crash，crash堆棧如下 3.0以前

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x00000028

Crashed Thread: 0

Thread 0 name: Dispatch queue: com.apple.main-thread

Thread 0 Crashed:

0 WebKit 0x393cfe62 -[WebView(WebPrivate) _loadBackForwardListFromOtherView:] + 130

1 MttHD 0x0009e364 -[UIWebViewWK loadUrlFromOtherWK:] (UIWebViewWK.mm:4741)

2 MttHD 0x0001a432 -[UIMttBrowserView preloadUrls:] (UIMttBrowserView.m:6341)

3 Foundation 0x33408652 __NSFireDelayedPerform + 446

4 CoreFoundation 0x32ace854 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 12

5 CoreFoundation 0x32ace4fe __CFRunLoopDoTimer + 270

6 CoreFoundation 0x32acd172 __CFRunLoopRun + 1226

7 CoreFoundation 0x32a40238 CFRunLoopRunSpecific + 352

8 CoreFoundation 0x32a400c4 CFRunLoopRunInMode + 100

9 GraphicsServices 0x365fb336 GSEventRunModal + 70

10 UIKit 0x3495c2b4 UIApplicationMain + 1116

11 MttHD 0x00003982 main (main.m:15)

12 MttHD 0x00003934 0x1000 + 10548

從上面crash線程的堆棧很難找到問題，再往下下面其它線程的堆棧；

Thread 16 name: Dispatch queue: com.apple.root.low-priority

Thread 16:

0 libsystem_kernel.dylib 0x3ae66e30 mach_msg_trap + 20

1 libsystem_kernel.dylib 0x3ae66fd0 mach_msg + 48

2 CoreFoundation 0x32ace2b6 __CFRunLoopServiceMachPort + 126

3 CoreFoundation 0x32acd02c __CFRunLoopRun + 900

4 CoreFoundation 0x32a40238 CFRunLoopRunSpecific + 352

5 CoreFoundation 0x32a400c4 CFRunLoopRunInMode + 100

6 CFNetwork 0x327a1612 CFURLConnectionSendSynchronousRequest + 330

7 Foundation 0x334353da +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242

8 MttHD 0x0019d76c __30-[MttSubscribeImage pullImage]_block_invoke_0 (MttSubscribeImage.m:310)

9 MttHD 0x0019eaca __41-[MttSubscribeTaskQueue dispatch:forKey:]_block_invoke_075 (MttSubscribeTaskQueue.m:161)

10 libdispatch.dylib 0x3ad9d790 _dispatch_call_block_and_release + 8

11 libdispatch.dylib 0x3ada1652 _dispatch_root_queue_drain + 274

12 libdispatch.dylib 0x3ada17d4 _dispatch_worker_thread2 + 88

13 libsystem_c.dylib 0x3adc57ee _pthread_wqthread + 358

14 libsystem_c.dylib 0x3adc5680 start_wqthread + 4

發現一個可疑的線程，該線程的堆棧正好跑完並等待中，恰好是有程序本身的代碼，通過review堆棧中的代碼發現，response變量沒有初始化。

NSHTTPURLResponse *response ;

self.data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error: nil];

為什麼沒有初始化會導致crash呢？因為sendSynchronousRequest 的 returningResponse變量是out型變量，則函數會把結果寫入returningResponse變量中，

當response沒有初始化的時候系統默認會給它一個隨機內存，sendSynchronousRequest 函數將內容寫入這塊隨機內存程序以後的運行很可能會導致隨機crash。

10、對象實例調用自身函數release自身實例導致crash 3.0以前

在MttVideoView類對象實例的dismissVideoView函數同步調用了closeVideoView將自身實例從UI樹移除並release自身，從而導致隨機crash，crash的堆棧

如下：

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0xc0000008

Crashed Thread: 0

Thread 0 name: Dispatch queue: com.apple.main-thread

Thread 0 Crashed:

0 libobjc.A.dylib 0x3358bc98 objc_msgSend + 16

1 CoreFoundation 0x36e33cd6 CFRetain + 62

2 CoreFoundation 0x36e3a176 +[__NSArrayI __new::] + 54

3 CoreFoundation 0x36e38a6e -[__NSPlaceholderArray initWithObjects:count:] + 122

4 QuartzCore 0x34c01db6 -[CALayerArray copyWithZone:] + 42

5 CoreFoundation 0x36e39b4a -[NSObject(NSObject) copy] + 10

6 UIKit 0x30e2bd7c -[UIView dealloc] + 52

7 MttHD 0x001e83e8 -[MttVideoView dealloc] (MttVideoView.m:378)

8 CoreFoundation 0x36e34c3c -[NSObject(NSObject) release] + 24

9 CoreFoundation 0x36e3519a CFRelease + 62

10 CoreFoundation 0x36e3aba2 -[__NSArrayM dealloc] + 86

11 CoreFoundation 0x36e34c3c -[NSObject(NSObject) release] + 24

12 CoreFoundation 0x36e3519a CFRelease + 62

13 CoreFoundation 0x36e37eb4 _CFAutoreleasePoolPop + 140

14 Foundation 0x33725bae NSPopAutoreleasePool + 2

15 Foundation 0x337aa73c __NSFireDelayedPerform + 472

16 CoreFoundation 0x36ea7a40 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8

17 CoreFoundation 0x36ea9ec4 __CFRunLoopDoTimer + 844

18 CoreFoundation 0x36eaa83e __CFRunLoopRun + 1082

19 CoreFoundation 0x36e3aebc CFRunLoopRunSpecific + 224

20 CoreFoundation 0x36e3adc4 CFRunLoopRunInMode + 52

21 GraphicsServices 0x31793418 GSEventRunModal + 108

22 GraphicsServices 0x317934c4 GSEventRun + 56

23 UIKit 0x30e32d62 -[UIApplication _run] + 398

24 UIKit 0x30e30800 UIApplicationMain + 664

25 MttHD 0x00003800 main (main.m:15)

26 MttHD 0x000037b0 0x1000 + 10160

這個是手動點擊刪除小窗口按鈕退出小窗口的，結合代碼分析，刪除這個實例的堆棧必須有函數closeVideoView ，但是從crash的堆棧上看，沒有發現函數closeVideoView的堆棧，

覺得很詭異，不符合堆棧邏輯。為什麼會出現上面的堆棧呢？是因為該實例的函數調用棧還沒有完成退出就調用自身的dealloc函數將自己刪除掉了，

導致棧上的地址出現隨機錯誤。

解決總結：要刪除實例自身，應該要用異步延時刪除，不能同步刪除。

11、加入手勢的對象發生了變化 bilsonzhou 3.0以前

Thread 2 Crashed:

0 libsystem_kernel.dylib 0x33db3a1c __pthread_kill + 8

1 libsystem_c.dylib 0x34aa73b4 pthread_kill + 52

2 libsystem_c.dylib 0x34a9fb78 __abort + 80

3 libsystem_c.dylib 0x34a9fc18 abort + 104

4 libstdc++.6.dylib 0x35470a64 __gnu_cxx::__verbose_terminate_handler() + 376

5 libobjc.A.dylib 0x32ce706c _objc_terminate + 104

6 libstdc++.6.dylib 0x3546ee36 __cxxabiv1::__terminate(void (*)()) + 46

7 libstdc++.6.dylib 0x3546ee8a std::terminate() + 10

8 libstdc++.6.dylib 0x3546ef5a __cxa_throw + 78

9 libobjc.A.dylib 0x32ce5c84 objc_exception_throw + 64

10 CoreFoundation 0x36593062 -[__NSArrayM objectAtIndex:] + 178

11 CoreFoundation 0x365ba130 -[NSMutableArray removeObject:range:identical:] + 284

12 CoreFoundation 0x365b9ffa -[NSMutableArray removeObject:] + 46

13 UIKit 0x305e31fe -[UIView(UIViewGestures) removeGestureRecognizer:] + 54

14 UIKit 0x305e3004 -[UIWebSelectionAssistant setGestureRecognizers] + 48

15 UIKit 0x305e4408 -[UIWebSelectionAssistant setEnabled:] + 48

16 UIKit 0x30664c70 -[UIWebDocumentView loadRequest:] + 168

17 CoreFoundation 0x3662b79c __invoking___ + 60

18 CoreFoundation 0x365a3436 -[NSInvocation invoke] + 102

19 WebCore 0x35c29c36 _ZL11SendMessageP12NSInvocation + 10

20 WebCore 0x35c29c0e _ZL15HandleAPISourcePv + 66

21 CoreFoundation 0x365ffa72 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 6

22 CoreFoundation 0x36601758 __CFRunLoopDoSources0 + 376

23 CoreFoundation 0x366024e4 __CFRunLoopRun + 224

24 CoreFoundation 0x36592ebc CFRunLoopRunSpecific + 224

25 CoreFoundation 0x36592dc4 CFRunLoopRunInMode + 52

26 WebCore 0x35c2827e _ZL12RunWebThreadPv + 382

27 libsystem_c.dylib 0x34aa730a _pthread_start + 242

28 libsystem_c.dylib 0x34aa8bb4 thread_start + 0

這是個隨機的bug，棧裡面也沒有我們的代碼。幸好4.3系統在騰訊視頻發生頁內跳轉之後該crash高概率出現了。

最後發現原因是；網頁的雙指單擊手勢加到了documentView上面，發生頁內跳轉之後documentView的內容發生了變化。在網頁釋放的時候就掛了。

修改方法是把手勢加到了網頁的scroll上面。

12、手勢crash. bilsonzhou 3.0以前 3.1修復

0 libobjc.A.dylib 0x3b41c692 0x3b419000 13970

1 MttHD 0x000fce4c -[GestureDetectWindow handleOneFingerPan:] (in MttHD) (GestureDetectWindow.m:237)

2 UIKit 0x354a6d88 0x35386000 1183112

3 UIKit 0x3546e3f4 0x35386000 951284

4 UIKit 0x3565ba38 0x35386000 2972216

5 UIKit 0x3539282e 0x35386000 51246

6 UIKit 0x35391292 0x35386000 45714

7 UIKit 0x3539c1e6 0x35386000 90598

8 UIKit 0x3539bdb2 0x35386000 89522

9 UIKit 0x35389800 0x35386000 14336

10 UIKit 0x3538911a 0x35386000 12570

11 GraphicsServices 0x370925a2 0x3708c000 26018

12 GraphicsServices 0x370921d2 0x3708c000 25042

13 CoreFoundation 0x33556172 0x334bf000 618866

14 CoreFoundation 0x33556116 0x334bf000 618774

15 CoreFoundation 0x33554f98 0x334bf000 614296

16 CoreFoundation 0x334c7ebc 0x334bf000 36540

17 CoreFoundation 0x334c7d48 0x334bf000 36168

18 GraphicsServices 0x370912ea 0x3708c000 21226

19 UIKit 0x353dd300 0x35386000 357120

20 MttHD 0x0000331e main (in MttHD) (main.m:15)

該crash在以前版本一直有上報，3.0更改手勢機制之後上報量突然增大。

在3.0灰度版本的時候就有上報，但是上報的棧指向的是MttBrowserView成了野指針。如果

browserview都成了野指針那整個浏覽器都野了，因此灰度之後排查了browserView中成員變量。對照3.0以前相關crash附近手勢的代碼進行了更改。

結果發出去之後還是有大量的上報。後來通過打印大量日志後發現，panGesture手勢的三個過程：

touch begin,move,end。不是每次調用都會進入move。而我們的變量初始化都放在了move當中，move沒有調用導致變量沒有初始化野指針crash.

這個地方日志上報的棧中的行數並不是確定的。

13、NSRange Exception crash bilsonzhou 3.2引入

0 CoreFoundation 0x36dde29e __exceptionPreprocess + 158

1 libobjc.A.dylib 0x3738697a objc_exception_throw + 26

2 CoreFoundation 0x36dde1c0 +[NSException raise:format:] + 100

3 Foundation 0x32ab175e -[NSData(NSData) subdataWithRange:] + 174

4 MttHD 0x002300bc -[MTTCommandTunnel _send] (MTTCommandTunnel.m:194)

5 MttHD 0x0022f950 -[MTTCommandTunnel streamHasSpaceAvailable:] (MTTCommandTunnel.m:126)

6 MttHD 0x0023025e -[MTTCommandTunnel stream:handleEvent:] (MTTCommandTunnel.m:239)

7 CoreFoundation 0x36d7b7ca _signalEventSync + 70

8 CoreFoundation 0x36d8161e _cfstream_solo_signalEventSync + 70

9 CoreFoundation 0x36d7b502 _CFStreamSignalEvent + 322

10 CFNetwork 0x32446862 CoreWriteStreamCFStreamSupport::coreStreamWriteEvent(__CoreWriteStream*, unsigned long) + 94

11 CFNetwork 0x32446218 CoreWriteStreamClient::coreStreamEventsAvailable(unsigned long) + 32

12 CFNetwork 0x324474c8 CoreStreamBase::_callClientNow() + 40

13 CFNetwork 0x3244725c CoreStreamBase::_streamSetEventAndScheduleDelivery(unsigned long, unsigned char) + 84

14 CFNetwork 0x32447662 CoreStreamBase::_streamInterface_SignalEvent(unsigned long, CFStreamError const*) + 30

15 CFNetwork 0x323b5c76 SocketStream::socketCallback(__CFSocket*, unsigned long, __CFData const*, void const*) + 130

16 CFNetwork 0x323b5bd6 SocketStream::_SocketCallBack_stream(__CFSocket*, unsigned long, __CFData const*, void const*, void*) + 70

17 CoreFoundation 0x36db5f18 __CFSocketPerformV0 + 792

18 CoreFoundation 0x36db367e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 10

19 CoreFoundation 0x36db2f7a __CFRunLoopDoSources0 + 358

20 CoreFoundation 0x36db1cb2 __CFRunLoopRun + 642

21 CoreFoundation 0x36d24eb8 CFRunLoopRunSpecific + 352

22 CoreFoundation 0x36d839b6 CFRunLoopRun + 94

23 MttHD 0x0022f7b6 -[MTTCommandTunnel tunnelThreadMain:] (MTTCommandTunnel.m:113)

24 Foundation 0x32b28678 __NSThread__main__ + 968

25 libsystem_c.dylib 0x337da30c _pthread_start + 304

26 libsystem_c.dylib 0x337da1d4 thread_start + 4

掛的原因是NSRange越界了。

NSInteger length = [self.outputStream write:self.sendBuffer.bytes maxLength:self.sendBuffer.length];

self.sendBuffer = [self.sendBuffer subdataWithRange:NSMakeRange(length, self.sendBuffer.length - length)].mutableCopy;

前一句代碼的寫動作出錯了，返回-1,由於NSRange為無符號型的，最後就發生溢出，成為一個超大整數發生越界。

對於會拋出異常的代碼，尤其是數組，字符串類操作比較多的代碼，最後try catch 一下。再通過和MTTEXCEPTIONLOG()在catch中輸出exception信息。

我添加了兩個新的log宏定義MTTERRORLOG()和MTTEXCEPTIONLOG(),這兩個宏在調試的時候會很顯眼的輸出錯誤信息，並且會將程序主動crash。

便於發現問題。發布版本不會收到影響。

14、initStringWithCString crash bilsonzhou 3.2引入

0 libsystem_c.dylib 0x31e43884 strlen + 12

1 CoreFoundation 0x329e4fa8 CFStringCreateWithCString + 12

2 MttHD 0x0022426e -[ShareView addFavoriteRequest:withPageURL:shareEntrance:] (ShareView.m:349)

3 MttHD 0x00223ac4 -[ShareView addFavoritePage] (ShareView.m:239)

4 MttHD 0x00223a64 -[ShareView canAddFavoritePage] (ShareView.m:231)

5 MttHD 0x002234e8 -[ShareView handleTouchUp:] (ShareView.m:118)

6 CoreFoundation 0x329e83f6 -[NSObject performSelector:withObject:withObject:] + 46

7 UIKit 0x34fb0e00 -[UIApplication sendAction:to:from:forEvent:] + 56

8 UIKit 0x34fb0dbc -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 24

9 UIKit 0x34fb0d9a -[UIControl sendAction:to:forEvent:] + 38

10 UIKit 0x34fb0b0a -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 486

11 UIKit 0x34fb1442 -[UIControl touchesEnded:withEvent:] + 470

12 UIKit 0x34faf924 -[UIWindow _sendTouchesForEvent:] + 312

13 UIKit 0x34faf312 -[UIWindow sendEvent:] + 374

14 DisplayRecorder.dylib 0x00bb5998 0xba9000 + 51608

15 UIKit 0x34f9568e -[UIApplication sendEvent:] + 350

16 UIKit 0x34f94f34 _UIApplicationHandleEvent + 5820

17 GraphicsServices 0x32b32224 PurpleEventCallback + 876

18 CoreFoundation 0x32a6251c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32

19 CoreFoundation 0x32a624be __CFRunLoopDoSource1 + 134

20 CoreFoundation 0x32a6130c __CFRunLoopRun + 1364

21 CoreFoundation 0x329e449e CFRunLoopRunSpecific + 294

22 CoreFoundation 0x329e4366 CFRunLoopRunInMode + 98

23 GraphicsServices 0x32b31432 GSEventRunModal + 130

24 UIKit 0x34fc3cce UIApplicationMain + 1074

25 MttHD 0x00003700 main (main.m:15)

26 MttHD 0x000036b0 0x1000 + 9904

通常NSString的函數如果傳入nil對象是會拋出異常的，但是initStringWithCString這個方法傳入nil對象是badexec錯誤。再調用的時候要記得判斷。

15 數據庫的單列進行多線程訪問 crash bilsonzhou 3.0以前引入

0 libsqlite3.dylib 0x3c321524 0x390a3524 (in libsqlite3.dylib) 5212

1 libsqlite3.dylib 0x3c31faae 0x390a1aae (in libsqlite3.dylib) 326

2 libsqlite3.dylib 0x3c317288 0x39099288 (in libsqlite3.dylib) 6288

3 libsqlite3.dylib 0x3c3060d0 0x390880d0 (in libsqlite3.dylib) 5776

4 libsqlite3.dylib 0x3c304980 0x39086980 (in libsqlite3.dylib) 244

5 libsqlite3.dylib 0x3c304144 0x39086144 (in libsqlite3.dylib) 300

6 libsqlite3.dylib 0x3c303c0e 0x39085c0e (in libsqlite3.dylib) 514

7 libsqlite3.dylib 0x3c30396e 0x3908596e (in libsqlite3.dylib) 262

8 libsqlite3.dylib 0x3c33a956 sqlite3_prepare_v2 (in libsqlite3.dylib) 30

9 MttHD 0x0020de14 -[FMDatabase executeQuery:withArgumentsInArray:orVAList:] (in MttHD) (FMDatabase.m:327)

10 MttHD 0x0020dfd8 -[FMDatabase executeQuery:] (in MttHD) (FMDatabase.m:432)

11 MttHD 0x0003fc0a -[MttHistoryManager mostVisitRecordByID:] (in MttHD) (MttHistoryManager.m:715)

12 MttHD 0x000410ce -[MttHistoryManager mostVisitStartPageRecord] (in MttHD) (MttHistoryManager.m:1141)

13 MttHD 0x001968f6 -[QuicklinkViewNew getUnLockItemCount] (in MttHD) (QuicklinkViewNew.m:1483)

14 MttHD 0x0012a490 -[MttHDStatInfo protocol] (in MttHD) (MttHDStatInfo.m:179)

15 MttHD 0x00114898 [MttSTStat(Adapter) mtthdInstance] (in MttHD) (MttSTStat Adapter.m:39)

16 MttHD 0x00122bec __52-[MttStatService statWithCompleteBlock:failedBlock:]_block_invoke_06 (in MttHD) (MttStatService.m:38)

17 libdispatch.dylib 0x3c52111e _dispatch_call_block_and_release (in libdispatch.dylib) 10

18 libdispatch.dylib 0x3c524ece _dispatch_queue_drain$VARIANT$mp (in libdispatch.dylib) 142

19 libdispatch.dylib 0x3c524dc0 _dispatch_queue_invoke$VARIANT$mp (in libdispatch.dylib) 40

20 libdispatch.dylib 0x3c52591c _dispatch_root_queue_drain (in libdispatch.dylib) 184

21 libdispatch.dylib 0x3c525ac0 _dispatch_worker_thread2 (in libdispatch.dylib) 84

22 libsystem_c.dylib 0x3c555a10 _pthread_wqthread (in libsystem_c.dylib) 360

多個線程都同時對數據庫進行訪問，造成沖突之後crash。

很多使用單例的地方，如果不做好同步，都有造成線程沖突crash的風險。

解決方法：由於子線程訪問數據庫的地方不多，將訪問數據庫都同步到了主線程。

16 進度條繪制和內核的圖片繪制沖突 bilsonzhou 3.0以前引入

Thread 0 Crashed:

0 CoreGraphics 0x3732b1b0 DYLD-STUB$$ceilf + 0

1 CoreGraphics 0x3723cc86 CGRectIntegral + 86

2 CoreGraphics 0x3724bb82 CGImageBlockCreate + 106

3 ImageIO 0x3349fc70 copyImageBlockSetPNG + 1820

4 ImageIO 0x3349f35e ImageProviderCopyImageBlockSetCallback + 202

5 CoreGraphics 0x3724baf6 CGImageProviderCopyImageBlockSetWithOptions + 226

6 CoreGraphics 0x3724ba00 CGImageProviderCopyImageBlockSet + 32

7 CoreGraphics 0x3724b72e img_blocks_create + 182

8 CoreGraphics 0x37247140 img_data_lock + 1656

9 CoreGraphics 0x372463b8 CGSImageDataLock + 104

10 libRIP.A.dylib 0x3477f63c ripc_AcquireImage + 2676

11 libRIP.A.dylib 0x3477cc52 ripc_DrawImage + 462

12 CoreGraphics 0x37246284 CGContextDelegateDrawImage + 44

13 CoreGraphics 0x37246142 CGContextDrawImage + 250

14 MttHD 0x000256f4 -[AJProgressLayer drawInContext:] (UIMttBrowserAddressField.m:89)

15 QuartzCore 0x34cbdd24 _ZL16backing_callbackP9CGContextPv + 32

16 QuartzCore 0x34cbd776 CABackingStoreUpdate + 1226

17 QuartzCore 0x34cbd178 -[CALayer _display] + 724

18 QuartzCore 0x34cbce86 -[CALayer display] + 134

19 QuartzCore 0x34cb1706 CALayerDisplayIfNeeded + 178

20 QuartzCore 0x34cb11c6 CA::Context::commit_transaction(CA::Transaction*) + 214

21 QuartzCore 0x34cb0fd0 CA::Transaction::commit() + 184

22 QuartzCore 0x34caa04e CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 50

23 CoreFoundation 0x36f72a2e __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 10

24 CoreFoundation 0x36f7445e __CFRunLoopDoObservers + 406

25 CoreFoundation 0x36f75754 __CFRunLoopRun + 848

26 CoreFoundation 0x36f05ebc CFRunLoopRunSpecific + 224

27 CoreFoundation 0x36f05dc4 CFRunLoopRunInMode + 52

28 GraphicsServices 0x3185e418 GSEventRunModal + 108

29 GraphicsServices 0x3185e4c4 GSEventRun + 56

30 UIKit 0x30efdd62 -[UIApplication _run] + 398

31 UIKit 0x30efb800 UIApplicationMain + 664

32 MttHD 0x00003578 main (main.m:15)

33 MttHD 0x00003528 0x1000 + 9512

mttf偶爾會有該棧的上報，老俞在訪問百度貼吧很多圖片的時候產生了該crash，在內核線程中也發現了drawInContext函數。

猜測CGContextDrawImage繪制圖片和內核繪制圖片產生了線程沖突。通過img的drawInRect函數重寫了進度條的繪制進行了規避。

17 UIImageWriteToSavedPhotosAlbum 會產生異常 3.2以前引入

0 CoreFoundation 0x341ae8be __exceptionPreprocess (in CoreFoundation) 162

1 libobjc.A.dylib 0x358ca1e4 objc_exception_throw (in libobjc.A.dylib) 32

2 CoreData 0x33b7064a -[NSPersistentStoreCoordinator setMetadata:forPersistentStore:] (in CoreData) 410

3 PhotoLibraryServices 0x328efbb8 [PLManagedObjectContext(Private) recordVersion:forStore:] (in PhotoLibraryServices) 392

4 PhotoLibraryServices 0x328f0022 [PLManagedObjectContext(Private) configurePersistentStoreCoordinator:] (in PhotoLibraryServices) 1122

5 PhotoLibraryServices 0x328f069a __69 [PLManagedObjectContext(Protected) sharedPersistentStoreCoordinator]_block_invoke_0346 (in PhotoLibraryServices) 178

6 libdispatch.dylib 0x374907ea _dispatch_barrier_sync_f_invoke (in libdispatch.dylib) 22

7 libdispatch.dylib 0x3749065a dispatch_barrier_sync_f$VARIANT$up (in libdispatch.dylib) 62

8 libdispatch.dylib 0x3749028e dispatch_sync_f$VARIANT$up (in libdispatch.dylib) 18

9 libdispatch.dylib 0x37490910 dispatch_sync$VARIANT$up (in libdispatch.dylib) 32

10 PhotoLibraryServices 0x328f059a [PLManagedObjectContext(Protected) sharedPersistentStoreCoordinator] (in PhotoLibraryServices) 154

11 PhotoLibraryServices 0x328eed94 -[PLManagedObjectContext initWithConcurrencyType:useSharedPersistentStoreCoordinator:] (in PhotoLibraryServices) 120

12 PhotoLibraryServices 0x328eec72 [PLManagedObjectContext contextForPhotoLibrary:] (in PhotoLibraryServices) 114

13 PhotoLibraryServices 0x328ee894 -[PLPhotoLibrary(Protected) loadDatabase] (in PhotoLibraryServices) 236

14 PhotoLibraryServices 0x328b7184 -[PLPhotoLibrary initWithPath:canTriggerDatabaseUpdate:] (in PhotoLibraryServices) 304

15 PhotoLibraryServices 0x328fe1a4 __42 [PLSharedPhotoLibrary sharedPhotoLibrary]_block_invoke_0 (in PhotoLibraryServices) 60

16 libdispatch.dylib 0x37492576 dispatch_once_f$VARIANT$up (in libdispatch.dylib) 42

17 PhotoLibraryServices 0x328fe162 [PLSharedPhotoLibrary sharedPhotoLibrary] (in PhotoLibraryServices) 82

18 PhotoLibraryServices 0x328bf06e __withSavedPhotosAlbumUUID_block_invoke_0 (in PhotoLibraryServices) 50

19 libdispatch.dylib 0x37492576 dispatch_once_f$VARIANT$up (in libdispatch.dylib) 42

20 PhotoLibraryServices 0x328be436 withSavedPhotosAlbumUUID (in PhotoLibraryServices) 186

21 PhotoLibraryServices 0x328be378 PLSaveImageToCameraRoll (in PhotoLibraryServices) 76

22 UIKit 0x354831d4 UIImageWriteToSavedPhotosAlbum (in UIKit) 76

23 MttHD 0x001b0eb0 -[MttImageArticleMainView tapButton:] (in MttHD) (MttImageArticleMainVIew.m:983)

24 CoreFoundation 0x34108434 -[NSObject performSelector:withObject:withObject:] (in CoreFoundation) 52

25 UIKit 0x352369ea -[UIApplication sendAction:to:from:forEvent:] (in UIKit) 62

26 UIKit 0x352369a6 -[UIApplication sendAction:toTarget:fromSender:forEvent:] (in UIKit) 30

27 UIKit 0x35236984 -[UIControl sendAction:to:forEvent:] (in UIKit) 44

28 UIKit 0x352366f4 -[UIControl(Internal) _sendActionsForEvents:withEvent:] (in UIKit) 492

29 UIKit 0x3523702c -[UIControl touchesEnded:withEvent:] (in UIKit) 476

30 UIKit 0x3523550e -[UIWindow _sendTouchesForEvent:] (in UIKit) 318

31 UIKit 0x35234f00 -[UIWindow sendEvent:] (in UIKit) 380

32 UIKit 0x3521b4ec -[UIApplication sendEvent:] (in UIKit) 356

33 UIKit 0x3521ad2c _UIApplicationHandleEvent (in UIKit) 5808

34 GraphicsServices 0x35d45df2 PurpleEventCallback (in GraphicsServices) 882

35 CoreFoundation 0x34182552 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ (in CoreFoundation) 38

36 CoreFoundation 0x341824f4 __CFRunLoopDoSource1 (in CoreFoundation) 140

37 CoreFoundation 0x34181342 __CFRunLoopRun (in CoreFoundation) 1370

38 CoreFoundation 0x341044dc CFRunLoopRunSpecific (in CoreFoundation) 300

39 CoreFoundation 0x341043a4 CFRunLoopRunInMode (in CoreFoundation) 104

40 GraphicsServices 0x35d44fcc GSEventRunModal (in GraphicsServices) 156

41 UIKit 0x35249742 UIApplicationMain (in UIKit) 1090

42 MttHD 0x0000377e main (in MttHD) (main.m:15)

43 MttHD 0x00003730 start (in MttHD) 40

UIImageWriteToSavedPhotosAlbum這個函數會拋出異常，在網頁圖片那塊保存到本地我就修改過一次。後來的同學估計不知道，又

沒有捕獲。看來分析還是很有必要的。

18、performSelector 操作會對對象本身retain一下。ranger bilsonzhou

由於異步操作會對對象本身進行一次retain，如果將異步操作放在delloc中cancel。會造成對象的延遲釋放，如果這時候對觀察者產生

回調的話就會有crash發生。

例如：

A->B->C

A做為B的觀察者向下傳遞，B中的C會回調到A中方法。

傳統的A的delloc方法中銷毀B，B的delloc方法中銷毀C。由於異步操作造成B延遲釋放，

A delloc之後，B沒有立即放生釋放，這時候B產生回調或者C發生回調，就會因為A的野指針crash。

搜索框的crash的根本原因也是這個，下面是crash棧

Thread 0:

0 libobjc.A.dylib 0x33a54c98 objc_msgSend + 16

1 MttHD 0x000547e4 -[UIToolbarSearchInputPopMenuController onGetAssociationOfInput:data:] (UIToolbarSearchInputPopMenuController.m:574)

2 MttHD 0x00203380 __block_global_0 (MttGetAssociationalService.m:58)

3 libdispatch.dylib 0x338669c2 _dispatch_barrier_sync_f_slow_invoke + 62

4 libdispatch.dylib 0x338670e6 _dispatch_main_queue_callback_4CF$VARIANT$mp + 282

5 CoreFoundation 0x37373934 __CFRunLoopRun + 1328

6 CoreFoundation 0x37303ebc CFRunLoopRunSpecific + 224

7 CoreFoundation 0x37303dc4 CFRunLoopRunInMode + 52

8 GraphicsServices 0x31c5c418 GSEventRunModal + 108

9 GraphicsServices 0x31c5c4c4 GSEventRun + 56

10 UIKit 0x312fbd62 -[UIApplication _run] + 398

11 UIKit 0x312f9800 UIApplicationMain + 664

12 MttHD 0x00003740 main (main.m:15)

13 MttHD 0x000036f0 0x1000 + 9968

- (void)onGetAssociationOfInput:(NSString *)keyWord data:(NSArray *)result

{

NSString* lastSearchKeyWord = keyWord;

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(loadSearchRecord) object:nil];

[[MttHDStatInfo theSpecial] statUserBehavior:MttHDUserBehavior_Receive_Associational];

NSString *searchString = self.searchString;

這個地方是搜索熱詞的回調代碼，這裡面的self在輸入彈出框消失的時候會先進行一次釋放，

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(loadSearchRecord) object:nil];

這句代碼會將異步對自身的retain再釋放一次。如果網絡情況差，熱詞回調慢於彈出框釋放，上面

的代碼的實際執行就會如下：

NSString* lastSearchKeyWord = keyWord;

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(loadSearchRecord) object:nil];

[[MttHDStatInfo theSpecial] statUserBehavior:MttHDUserBehavior_Receive_Associational];

[self release];

[self delloc];

//這時候self已經野了，這句話以執行就會野指針掛掉

NSString *searchString = self.searchString;

這個crash的隨機性很高，通常情況時熱詞先回來，彈出框再消失就不會發生，只有在網絡回調慢的時候才會發生。

針對這種情況，需要對有異步操作的函數寫一個destroy函數來cancel異步操作，在觀察者發生釋放的時候調用destroy函數。以達到同步釋放

後續這塊會對異步操作進行梳理。

19、代理對象被釋放，delegate沒有設置Nil，delegate回調野指針導致block發生crash. 3.2引入 bilsonzhou

0 libobjc.A.dylib 0x317dff78 objc_msgSend (in libobjc.A.dylib) 16

1 libdispatch.dylib 0x3491fc58 _dispatch_call_block_and_release (in libdispatch.dylib) 12

2 libdispatch.dylib 0x34921ee6 _dispatch_main_queue_callback_4CF$VARIANT$mp (in libdispatch.dylib) 194

3 CoreFoundation 0x377432ac __CFRunLoopRun (in CoreFoundation) 1268

4 CoreFoundation 0x376c64a4 CFRunLoopRunSpecific (in CoreFoundation) 300

5 CoreFoundation 0x376c636c CFRunLoopRunInMode (in CoreFoundation) 104

6 GraphicsServices 0x378bf438 GSEventRunModal (in GraphicsServices) 136

7 UIKit 0x308d2cd4 UIApplicationMain (in UIKit) 1080

8 MttHD 0x00003ace main (in MttHD) (main.m:15)

訂閱第二屏subscribItem被釋放了，但是wup回調的delegate沒有被設置空。

在讀取數據的輪詢函數中，將

if(imageData == nil)

{

return;

}

注釋掉了。

之後下面的：

[_subscribeWupManager release];

_sbuscribeWupManager = nil;

代碼被調用，在弱網絡環境下，wup的回調如果還沒有回來，這個時候由於wup裡面的block會retain _subscribeWupManager自身。

當 subscribItem delloc的時候調用 _subscribeWupManager.delegate = nil;這時候的_subscribeWupManager已經是一個指向

nil的指針。而真正的_subscribeWupManager此時並沒有釋放，但是它的delegate已經釋放，這時候發生回調就發生Crash了.