在實際工作當中，通過會出現某個應用造成宕機問題。如何解決該問題。
方法一：最簡單辦法，看列印，通過反覆除錯，看是哪條語句造成造成了宕機。這種方法效率低，而且有時不準確，比如乙個系統中有多個程序，但a程序跑的b斷點是，出現段錯誤，系統發出11號訊號，造成b，c等程序接到11號訊號反初始化而推出。實際當中可能不一定是a程序原因，因為此時b，c等程序也在併發執行，甚至a，b，c 三個程序都在訪問某一共享資源（如共享記憶體等）。
核心預設是不支援oops列印，需要核心配置開關開啟。通常內為了了優化效能，除錯開關都不會開啟，需要我們根據實際需要開啟某些除錯開關。
簡單情況：
從oops知道pc指標，如果該程序是沒有呼叫庫，可以直接將該程序反彙編 objdump -d -s ***程序名》124.txt
再從123.txt找到該pc指標位置對於的c**行，即可定位。
對於情況還可以使用addr2line pc指標 -e ***x程序名 -f定位到某個c**行
複雜情況：
如果乙個程序包含很多庫，甚至要呼叫底層驅動，定位起來就更加麻煩。
首先看pc指標位址確認是在死在核心態和使用者態。還是ko模組，不同處理器架構不一樣，可以看核心位址對映表 system.map
比如在mips系統中
如果在使用者空間：
首先通過cat /proc./pid/maps
檢視 pc=***x 指標所在庫，比如pc指標所在庫為***.so ,而xx.so的位址訪問為aaa~bbb
那麼pc指標再 ***.so庫中偏移位址為***-aaa=ccc
對***.so 進行反彙編，objdump -d -s >345.txt
查詢到ccc行就能找到對應行。
注意該程序以及改程序所在的庫編譯是必需加-g ,也不能strip，否則反彙編出來沒有c**的對映行
如果是在核心空間，可以通過堆疊回溯法程序回溯。該方法需要熟悉彙編，其次需要耐心，這裡不詳述。
堆疊回溯法出來oops
通過反彙編，然後堆疊回溯，找到出問題的函式，該方法需要熟悉彙編，其次需要耐心，這裡不詳述。
方法三：coredump分析法
對於宕機問題，某些情況下oops列印出來的資訊不足以分析。coredump給了個詳細的方法。
首先在核心當中開啟coredup 開關，宕機後就會產生乙個core問題，事後可以通過 gdb除錯方法來分析定位宕機的位置。
由於版本依賴造成的YUM段錯誤
最近在伺服器 centos 5.3，64位 上使用yum，總是提示 segmentation fault，無論執行什麼命令都是如此，一時不得其解。查了一些資料，大體上說是由於zlib版本造成的。檢視了一下，發現最近確實安裝了zlib的1.2.5版本，而造成了yum的依賴問題。網上資料中顯示問題排查時...
匯流排錯誤和段錯誤問題的定位
對現在的很多初級的程式原來說如果遇到 匯流排錯誤 bus error 或者段錯誤 segementation fault core dump 是一件非常折磨人的事，讓人一時間找不到什麼好的方法也不知從何處下手去解決這個問題 和許多人一樣，我很快也遇到了這樣的問題 出現這個錯誤時，錯誤資訊對引起這種事...
Linux開發中常見段錯誤問題原因分析
1 使用非法的記憶體位址 指標 包括使用未經初始化及已經釋放的指標 不存在的位址 受系統保護的位址，唯讀的位址等，這一類也是最常見和最好解決的段錯誤問題，使用gdb print一下即可知道原因。2 記憶體讀 寫越界。包括陣列訪問越界，或在使用一些寫記憶體的函式時，長度指定不正確或者這些函式本身不能指...