進(jìn)程跟蹤和調(diào)試
DTrace
DTrace中的“D”指的是D語言。這是一門完整的跟蹤語言谤专，通過這門語言可以創(chuàng)建專門的跟蹤器（tracer）或者探測器（probe）
druss 工具是一個底層為DTrac的工具屋厘，允許跟蹤系統(tǒng)調(diào)用時打印出C風(fēng)格的形式黄痪，顯示系統(tǒng)調(diào)用、參數(shù)及返回值睬隶。druss支持3種使用模式：
- 通過druss 允許一個進(jìn)程：在druss 的參數(shù)后面指定命令參數(shù)
- 附加到某個正在允許的進(jìn)程示例：在druss -p 參數(shù)指定進(jìn)程的PID
- 附加到命名的進(jìn)程：在druss -n 參數(shù)指定進(jìn)程的名字
druss 的另一個有用的特性是能夠自動鎖定子進(jìn)程（指定 -f 參數(shù)）
druss 還可以同時當(dāng)場跟蹤器和剖析器使用
進(jìn)程信息
除了DTrace 之外，OS X 還提供了兩個關(guān)鍵機(jī)制可以查看詳細(xì)的進(jìn)程信息
- sysctl：sysctl 提供了一些顯示進(jìn)程統(tǒng)計數(shù)據(jù)的變量
- proc_info：OS X 和 iOS 都提供了proc_info 系統(tǒng)調(diào)用页徐。通過proc_info 可以查詢進(jìn)程和線程的很多信息
進(jìn)程和系統(tǒng)快照
除了 DTrace 和 Instruments 之外苏潜，在 OS X 中還有一些工具能夠獲得系統(tǒng)或進(jìn)程狀態(tài)的“快照”（snapshot）
- system_profiler( )：圖形工具
- sysdiagnose( )：是一個一站式的完美診斷工具
- allmemory( )：捕獲用戶進(jìn)程的所有內(nèi)存使用情況
- stackshot( )：可以獲得進(jìn)程執(zhí)行狀態(tài)的快照
- *stack_sanpshot系統(tǒng)調(diào)用：這個系統(tǒng)調(diào)用的參數(shù)是pid、一個返回快照的緩沖區(qū)变勇、緩沖區(qū)大小以及一些參數(shù)恤左。這個快照機(jī)制的實現(xiàn)細(xì)節(jié)會深入到Mach微內(nèi)核中
kdebug
kdebug 是內(nèi)建內(nèi)核跟蹤設(shè)施。默認(rèn)是禁用的
OS X 提供了3個利用kdebug 設(shè)施的工具
- sc_usage：顯示每一個進(jìn)程的系統(tǒng)調(diào)用信息
- fs_usage：顯示系統(tǒng)調(diào)用搀绣，但是顯示的是與文件飞袋、套接字和目錄相關(guān)的應(yīng)用×椿迹可以顯示系統(tǒng)范圍內(nèi)的跟蹤（除非調(diào)用時提供了PID 或 命令參數(shù)）
- latency：顯示中斷和調(diào)度的延遲值巧鸭。這個工具展示落在閾值內(nèi)的上下文切換和中斷處理程序技術(shù)，這兩個分別可以通過-st 和 -it 參數(shù)設(shè)置
應(yīng)用程序崩潰
大部分應(yīng)用程序都可能會崩潰麻捻。在UNIX 中纲仍，崩潰和一個信號有關(guān)。崩潰的真正原因來自于內(nèi)核贸毕，內(nèi)核發(fā)現(xiàn)進(jìn)程無法繼續(xù)執(zhí)行時郑叠，生成這個信號作為最后的補(bǔ)救方法
- 核心轉(zhuǎn)儲：當(dāng)一個進(jìn)程崩潰時，可以選擇是否生成核心轉(zhuǎn)儲文件崖咨。這取決于進(jìn)程的資源限制RLIMIT_CORE的設(shè)置锻拘。默認(rèn)情況下是禁止的
- Crash Reporter：iOS 和 OS X 都沒有選擇創(chuàng)建巨大的核心轉(zhuǎn)儲文件，而是包含一個Crash Reporter，當(dāng)進(jìn)程異常終止（崩潰）時自動觸發(fā)Crash Reporter生成詳細(xì)的崩潰日志署拟，保存在用戶的Library/Logs/CrashReporter目錄下或者系統(tǒng)的Library/Logs/CrashReporter目錄下
- 修改Crash Repoerter 選項：如果安裝了Xcode婉宰，那么可以在 /Developer/Application/Utilities 目錄下找到一個名為CrashReporter的小程序。啟動程序
- defaults( )：將DialogType 屬性修改為basic推穷、developer 或 server
內(nèi)存破壞的bug
內(nèi)存破壞是程序中常見的bug來源心包。應(yīng)用程序崩潰的主要原因就是緩沖區(qū)溢出（既包含棧也包含堆）和堆內(nèi)存的破壞。問題在于馒铃，在很多情況下蟹腾，導(dǎo)致問題的代碼和出現(xiàn)問題的代碼相隔甚遠(yuǎn)，因此從出現(xiàn)bug到引發(fā)崩潰之間肯呢個會間隔數(shù)分鐘甚至更長時間
- LibC中的內(nèi)存保護(hù)：OS X 的LibC庫高度可配置区宇，malloc( ) 的手冊頁記錄了可以控制內(nèi)存分配行為的環(huán)境變量娃殖，如下表
| 環(huán)境變量 | 用途 |
|---|---|
| MallocLogFile | 設(shè)置malloc調(diào)試日志文件 |
| MallocCheckHeapStart MallocCheckHeapEach MallocCheckHeapSleep/Abort |
在MallocCheckHeapStart 次分配后，每隔MallocCheckHeapEach 次分配之后檢查堆的一致性议谷。如果發(fā)現(xiàn)堆不一致的情況炉爆，要么進(jìn)入睡眠（允許調(diào)試），要么調(diào)用abort( )（通過SIGABRT 崩潰） |
| MallocErrorAbort MallocCorruptionAbort |
發(fā)送任何錯誤時調(diào)用abort( )（即發(fā)送 SIGABRT 信號）卧晓，或只有內(nèi)存破壞時調(diào)用abort( ) |
| MallocGuardEdges MallocDoNotProtectPrelude MallocDoNotProtectPostlude |
在分配的大內(nèi)存塊之前（如果沒有設(shè)置MallocDoNotProtectPrelude）和之后（如果沒有設(shè)置MallocDoNotProtectPostlude）添加守護(hù)頁 |
| MallocScribble | 在分配的內(nèi)存中填滿0xAA芬首，在釋放的內(nèi)存中填滿0x55 |
| MallocStackLogging MallocStackLoggingNoCompact MallocStackLoggingDirectory |
將malloc操作時所用的棧跟蹤記錄到/tmp(或 MallocStackLoggingDirectory 指定的目錄)中。然后可以調(diào)用 leaks( ) 和 malloc_history( ) 之類的程序逼裆，后者要求設(shè)置MallocStackLoggingNoCompact |
LibGMalloc：OS X 還提供了一個特殊的庫libgmalloc.dylib郁稍，這個庫可以截獲并調(diào)試分配內(nèi)存。這個強(qiáng)大的庫的工作原理是截獲LibSystem 中的分配函數(shù)胜宇，一旦掛上了目標(biāo)函數(shù)耀怜，就可以很容易地將其替換為更復(fù)雜的替代品，從而對內(nèi)存分配施加更多的限制掸屡，以期能夠捕捉到導(dǎo)致崩潰的蛛絲馬跡
具體來說封寞，libgmalloc庫提供了以下的技術(shù)
- 給么一個分配的內(nèi)存塊加上自定義的數(shù)據(jù)頭，其中包含了關(guān)于分配詳情的調(diào)試信息：這個數(shù)據(jù)頭記錄了分配時的線程ID 和 椊霾疲回溯狈究，還帶有一個常量值（魔數(shù)）0xDEADBEEF，這個常量值可以用于檢測同一個緩沖區(qū)分配和解除分配的錯誤盏求。
-
將內(nèi)存塊分配在自己專有的頁面上抖锥，將相鄰的頁面設(shè)置為不可寫（如果設(shè)置了MALLOC_ALLOW_READS），或者設(shè)置為完全不可訪問：分配的內(nèi)存塊也放在其所在頁面的尾部（除非設(shè)置了MALLOC_PROTECT_BEFORE）碎罚。這樣做的結(jié)果就是任何讀/寫操作如果越過了緩沖區(qū)的尾部就會導(dǎo)致讀寫操作越過頁邊界磅废，從而導(dǎo)致越過未處理的頁錯誤，使得進(jìn)程收到總線錯誤的信號（SIGBUS）而崩潰荆烈。設(shè)置MALLOC_PROTECT_BEFORE 環(huán)境變量會將這個保護(hù)行為翻轉(zhuǎn)過來拯勉，即保護(hù)緩沖區(qū)之前不能被訪問竟趾，而不是保護(hù)緩沖區(qū)后面
-釋放內(nèi)存塊時接觸分配頁面：在free( ) 釋放內(nèi)存塊同時解除分配其所在頁，這樣的話宫峦，如果在釋放的緩沖區(qū)上進(jìn)行讀寫操作會導(dǎo)致總線錯誤
自動發(fā)生總線錯誤表示存在頁面處理的 bug岔帽，一旦發(fā)生，就使得調(diào)試變得相對簡單导绷。將 gdb 附加到進(jìn)程上犀勒，可以定位崩潰的位置，然后檢查這個自定義的數(shù)據(jù)頭妥曲，判斷分配相關(guān)的問題贾费，最后修復(fù)問題：要么修改緩沖區(qū)分配的參數(shù)。要么移除出錯的操作
內(nèi)存泄露
另外一個常見的bug 就是內(nèi)存泄露檐盟。當(dāng)程序員分配了內(nèi)存或某個對象褂萧，但是忘記調(diào)用free( )釋放內(nèi)存或調(diào)用delete 刪除對象時，就會發(fā)生能吃泄露遵堵。內(nèi)存泄露的問題很難查找箱玷，因為內(nèi)存泄露不會導(dǎo)致致命的bug 。而是慢慢地填滿進(jìn)程內(nèi)存空間陌宿，因為一旦一個指針丟失了，在程序運(yùn)行時波丰，就再也無法回收這個指針指向的內(nèi)存了壳坪。
Xcode 的 Instruments 工具提供了針對跟著內(nèi)存分配和泄露的工具（如下圖）
- heap( )：列出給定進(jìn)程的堆中所有分配的緩沖區(qū)，使用很簡單掰烟，只要傳入PID或部分進(jìn)程的名字即可。這個工具可以識別類的名字纫骑，所以對Objective-C 編譯的二進(jìn)制文件和依賴 CoreFundation 的庫非常有用
- leaks( )：遍歷進(jìn)程的堆蝎亚，檢查可疑的內(nèi)存泄露，對進(jìn)程進(jìn)行采樣先馆，生成一個分配但是沒有釋放的指針的報告
- malloc_history( )：malloc_history( ) 工具提供了進(jìn)程中發(fā)生的每一次內(nèi)存分配的詳細(xì)數(shù)據(jù)发框，包括dyld( ) 進(jìn)行的那些初始內(nèi)存分配，要求設(shè)置 MallocStackLogging 和 MallocStackLoggingNoCompact 環(huán)境變量
標(biāo)準(zhǔn) UNIX 工具
- **ps( ) **：可以顯示進(jìn)程列表
- top( ) 系統(tǒng)全局視圖：獲取當(dāng)前系統(tǒng)運(yùn)行狀況的關(guān)鍵工具
- 通過lsof( ) 和 fuser( ) 進(jìn)行文件診斷：lsof( ) 顯示一個進(jìn)程所有文件描述符（包括套接字）的映射; fuser( ) 提供一個反向的映射煤墙，從文件到用于這個文件的進(jìn)程梅惯。主要作用的診斷文件鎖定或者“文件被占用”的問題
