欧美日韩极品在线观看一区,欧美日韩精选,91久久线看在观草草青青

2008年3月

日

一

二

三

四

五

六

統(tǒng)計(jì)

隨筆 - 85
文章 - 0
評(píng)論 - 17
引用 - 0

常用鏈接

留言簿(6)

隨筆分類

鏈接 (rss)

隨筆檔案

收藏夾

資源(4) (rss)

全是知識(shí)啊

Linux靜態(tài)/動(dòng)態(tài)鏈接庫的創(chuàng)建和使用
http://www.advancedlinuxprogramming.com/alp-folder
LINUX動(dòng)態(tài)鏈接庫高級(jí)應(yīng)用
Linux軟件下載源碼編程文章資料
MDA之路的Blog
socket網(wǎng)絡(luò)教學(xué)篇
Socket中如何設(shè)置連接超時(shí)
高級(jí)shell編程指南
高級(jí)shell編程指南pdf版

搜索

閱讀排行榜

評(píng)論排行榜

在Linux上找出并解決程序錯(cuò)誤的主要方法

來源：http://www.y768.com/content/view/5755/109/

Steve Best（sbest@us.ibm.com）
JFS 核心小組成員，IBM
2002 年 8 月
您可以用各種方法來監(jiān)控運(yùn)行著的用戶空間程序：可以為其運(yùn)行調(diào)試器并單步調(diào)試該程序，添加打印語句，或者添加工具來分析程序。本文描述了幾種可以用來調(diào)試在 Linux 上運(yùn)行的程序的方法。我們將回顧四種調(diào)試問題的情況，這些問題包括段錯(cuò)誤，內(nèi)存溢出和泄漏，還有掛起。
本文討論了四種調(diào)試 Linux 程序的情況。在第 1 種情況中，我們使用了兩個(gè)有內(nèi)存分配問題的樣本程序，使用 MEMWATCH 和 Yet Another Malloc Debugger（YAMD）工具來調(diào)試它們。在第 2 種情況中，我們使用了 Linux 中的 strace 實(shí)用程序，它能夠跟蹤系統(tǒng)調(diào)用和信號(hào)，從而找出程序發(fā)生錯(cuò)誤的地方。在第 3 種情況中，我們使用 Linux 內(nèi)核的 Oops 功能來解決程序的段錯(cuò)誤，并向您展示如何設(shè)置內(nèi)核源代碼級(jí)調(diào)試器（kernel source level debugger，kgdb），以使用 GNU 調(diào)試器（GNU debugger，gdb）來解決相同的問題；kgdb 程序是使用串行連接的 Linux 內(nèi)核遠(yuǎn)程 gdb。在第 4 種情況中，我們使用 Linux 上提供的魔術(shù)鍵控順序（magic key sequence）來顯示引發(fā)掛起問題的組件的信息。

常見調(diào)試方法
當(dāng)您的程序中包含錯(cuò)誤時(shí)，很可能在代碼中某處有一個(gè)條件，您認(rèn)為它為真（true），但實(shí)際上是假（false）。找出錯(cuò)誤的過程也就是在找出錯(cuò)誤后推翻以前一直確信為真的某個(gè)條件過程。

以下幾個(gè)示例是您可能確信成立的條件的一些類型：

在源代碼中的某處，某變量有特定的值。
在給定的地方，某個(gè)結(jié)構(gòu)已被正確設(shè)置。
對(duì)于給定的 if-then-else 語句，if 部分就是被執(zhí)行的路徑。
當(dāng)子例程被調(diào)用時(shí)，該例程正確地接收到了它的參數(shù)。

找出錯(cuò)誤也就是要確定上述所有情況是否存在。如果您確信在子例程被調(diào)用時(shí)某變量應(yīng)該有特定的值，那么就檢查一下情況是否如此。如果您相信 if 結(jié)構(gòu)會(huì)被執(zhí)行，那么也檢查一下情況是否如此。通常，您的假設(shè)都會(huì)是正確的，但最終您會(huì)找到與假設(shè)不符的情況。結(jié)果，您就會(huì)找出發(fā)生錯(cuò)誤的地方。

調(diào)試是您無法逃避的任務(wù)。進(jìn)行調(diào)試有很多種方法，比如將消息打印到屏幕上、使用調(diào)試器，或只是考慮程序執(zhí)行的情況并仔細(xì)地揣摩問題所在。

在修正問題之前，您必須找出它的源頭。舉例來說，對(duì)于段錯(cuò)誤，您需要了解段錯(cuò)誤發(fā)生在代碼的哪一行。一旦您發(fā)現(xiàn)了代碼中出錯(cuò)的行，請(qǐng)確定該方法中變量的值、方法被調(diào)用的方式以及關(guān)于錯(cuò)誤如何發(fā)生的詳細(xì)情況。使用調(diào)試器將使找出所有這些信息變得很簡單。如果沒有調(diào)試器可用，您還可以使用其它的工具。（請(qǐng)注意，產(chǎn)品環(huán)境中可能并不提供調(diào)試器，而且 Linux 內(nèi)核沒有內(nèi)建的調(diào)試器。）

實(shí)用的內(nèi)存和內(nèi)核工具
您可以使用 Linux 上的調(diào)試工具，通過各種方式跟蹤用戶空間和內(nèi)核問題。請(qǐng)使用下面的工具和技術(shù)來構(gòu)建和調(diào)試您的源代碼：
用戶空間工具：

內(nèi)存工具：MEMWATCH 和 YAMD
strace
GNU 調(diào)試器（gdb）
魔術(shù)鍵控順序

內(nèi)核工具：

內(nèi)核源代碼級(jí)調(diào)試器（kgdb）
內(nèi)建內(nèi)核調(diào)試器（kdb）
Oops

本文將討論一類通過人工檢查代碼不容易找到的問題，而且此類問題只在很少見的情況下存在。內(nèi)存錯(cuò)誤通常在多種情況同時(shí)存在時(shí)出現(xiàn)，而且您有時(shí)只能在部署程序之后才能發(fā)現(xiàn)內(nèi)存錯(cuò)誤。

第 1 種情況：內(nèi)存調(diào)試工具
C 語言作為 Linux 系統(tǒng)上標(biāo)準(zhǔn)的編程語言給予了我們對(duì)動(dòng)態(tài)內(nèi)存分配很大的控制權(quán)。然而，這種自由可能會(huì)導(dǎo)致嚴(yán)重的內(nèi)存管理問題，而這些問題可能導(dǎo)致程序崩潰或隨時(shí)間的推移導(dǎo)致性能降級(jí)。

內(nèi)存泄漏（即 malloc() 內(nèi)存在對(duì)應(yīng)的 free() 調(diào)用執(zhí)行后永不被釋放）和緩沖區(qū)溢出（例如對(duì)以前分配到某數(shù)組的內(nèi)存進(jìn)行寫操作）是一些常見的問題，它們可能很難檢測(cè)到。這一部分將討論幾個(gè)調(diào)試工具，它們極大地簡化了檢測(cè)和找出內(nèi)存問題的過程。

MEMWATCH
MEMWATCH 由 Johan Lindh 編寫，是一個(gè)開放源代碼 C 語言內(nèi)存錯(cuò)誤檢測(cè)工具，您可以自己下載它（請(qǐng)參閱本文后面部分的參考資料）。只要在代碼中添加一個(gè)頭文件并在 gcc 語句中定義了 MEMWATCH 之后，您就可以跟蹤程序中的內(nèi)存泄漏和錯(cuò)誤了。MEMWATCH 支持 ANSI C，它提供結(jié)果日志紀(jì)錄，能檢測(cè)雙重釋放（double-free）、錯(cuò)誤釋放（erroneous free）、沒有釋放的內(nèi)存（unfreed memory）、溢出和下溢等等。

清單 1. 內(nèi)存樣本（test1.c）
#include "STDLIB.H"
#include "STDIO.H"
#include "memwatch.h"

int main(void)
{
char *ptr1;
char *ptr2;

ptr1 = malloc(512);
ptr2 = malloc(512);

ptr2 = ptr1;
free(ptr2);
free(ptr1);
}

清單 1 中的代碼將分配兩個(gè) 512 字節(jié)的內(nèi)存塊，然后指向第一個(gè)內(nèi)存塊的指針被設(shè)定為指向第二個(gè)內(nèi)存塊。結(jié)果，第二個(gè)內(nèi)存塊的地址丟失，從而產(chǎn)生了內(nèi)存泄漏。

現(xiàn)在我們編譯清單 1 的 memwatch.c。下面是一個(gè) makefile 示例：

test1
gcc -DMEMWATCH -DMW_STDIO test1.c memwatch
c -o test1

當(dāng)您運(yùn)行 test1 程序后，它會(huì)生成一個(gè)關(guān)于泄漏的內(nèi)存的報(bào)告。清單 2 展示了示例 memwatch.log 輸出文件。

清單 2. test1 memwatch.log 文件
MEMWATCH 2.67 Copyright (C) 1992-1999 Johan Lindh

...
double-free: <4> test1.c(15), 0x80517b4 was freed from test1.c(14)
...
unfreed: <2> test1.c(11), 512 bytes at 0x80519e4
{FE FE FE FE FE FE FE FE FE FE FE FE ..............}

Memory usage statistics (global):
N)umber of allocations made: 2
L)argest memory usage : 1024
T)otal of all alloc() calls: 1024
U)nfreed bytes totals : 512

MEMWATCH 為您顯示真正導(dǎo)致問題的行。如果您釋放一個(gè)已經(jīng)釋放過的指針，它會(huì)告訴您。對(duì)于沒有釋放的內(nèi)存也一樣。日志結(jié)尾部分顯示統(tǒng)計(jì)信息，包括泄漏了多少內(nèi)存，使用了多少內(nèi)存，以及總共分配了多少內(nèi)存。

YAMD
YAMD 軟件包由 Nate Eldredge 編寫，可以查找 C 和 C++ 中動(dòng)態(tài)的、與內(nèi)存分配有關(guān)的問題。在撰寫本文時(shí)，YAMD 的最新版本為 0.32。請(qǐng)下載 yamd-0.32.tar.gz（請(qǐng)參閱參考資料）。執(zhí)行 make 命令來構(gòu)建程序；然后執(zhí)行 make install 命令安裝程序并設(shè)置工具。

一旦您下載了 YAMD 之后，請(qǐng)?jiān)?test1.c 上使用它。請(qǐng)刪除 #include memwatch.h 并對(duì) makefile 進(jìn)行如下小小的修改：

使用 YAMD 的 test1
gcc -g test1.c -o test1

清單 3 展示了來自 test1 上的 YAMD 的輸出。

清單 3. 使用 YAMD 的 test1 輸出
YAMD version 0.32
Executable: /usr/src/test/yamd-0.32/test1
...
INFO: Normal allocation of this block
Address 0x40025e00, size 512
...
INFO: Normal allocation of this block
Address 0x40028e00, size 512
...
INFO: Normal deallocation of this block
Address 0x40025e00, size 512
...
ERROR: Multiple freeing At
free of pointer already freed
Address 0x40025e00, size 512
...
WARNING: Memory leak
Address 0x40028e00, size 512
WARNING: Total memory leaks:
1 unfreed allocations totaling 512 bytes

*** Finished at Tue ... 10:07:15 2002
Allocated a grand total of 1024 bytes 2 allocations
Average of 512 bytes per allocation
Max bytes allocated at one time: 1024
24 K alloced internally / 12 K mapped now / 8 K max
Virtual program size is 1416 K
End.

YAMD 顯示我們已經(jīng)釋放了內(nèi)存，而且存在內(nèi)存泄漏。讓我們?cè)谇鍐?4 中另一個(gè)樣本程序上試試 YAMD。

清單 4. 內(nèi)存代碼（test2.c）
#include "STDLIB.H"
#include "STDIO.H"

int main(void)
{
char *ptr1;
char *ptr2;
char *chptr;
int i = 1;
ptr1 = malloc(512);
ptr2 = malloc(512);
chptr = (char *)malloc(512);
for (i; i <= 512; i++) {
chptr = 'S';
}
ptr2 = ptr1;
free(ptr2);
free(ptr1);
free(chptr);
}

您可以使用下面的命令來啟動(dòng) YAMD：

./run-yamd /usr/src/test/test2/test2
清單 5 顯示了在樣本程序 test2 上使用 YAMD 得到的輸出。YAMD 告訴我們?cè)?for 循環(huán)中有“越界（out-of-bounds）”的情況。

清單 5. 使用 YAMD 的 test2 輸出
Running /usr/src/test/test2/test2
Temp output to /tmp/yamd-out.1243
*********
./run-yamd: line 101: 1248 Segmentation fault (core dumped)
YAMD version 0.32
Starting run: /usr/src/test/test2/test2
Executable: /usr/src/test/test2/test2
Virtual program size is 1380 K
...
INFO: Normal allocation of this block
Address 0x40025e00, size 512
...
INFO: Normal allocation of this block
Address 0x40028e00, size 512
...
INFO: Normal allocation of this block
Address 0x4002be00, size 512
ERROR: Crash
...
Tried to write address 0x4002c000
Seems to be part of this block:
Address 0x4002be00, size 512
...
Address in question is at offset 512 (out of bounds)
Will dump core after checking heap.
Done.

MEMWATCH 和 YAMD 都是很有用的調(diào)試工具，它們的使用方法有所不同。對(duì)于 MEMWATCH，您需要添加包含文件 memwatch.h 并打開兩個(gè)編譯時(shí)間標(biāo)記。對(duì)于鏈接（link）語句，YAMD 只需要 -g 選項(xiàng)。

Electric Fence
多數(shù) Linux 分發(fā)版包含一個(gè) Electric Fence 包，不過您也可以選擇下載它。Electric Fence 是一個(gè)由 Bruce Perens 編寫的 malloc() 調(diào)試庫。它就在您分配內(nèi)存后分配受保護(hù)的內(nèi)存。如果存在 fencepost 錯(cuò)誤（超過數(shù)組末尾運(yùn)行），程序就會(huì)產(chǎn)生保護(hù)錯(cuò)誤，并立即結(jié)束。通過結(jié)合 Electric Fence 和 gdb，您可以精確地跟蹤到哪一行試圖訪問受保護(hù)內(nèi)存。Electric Fence 的另一個(gè)功能就是能夠檢測(cè)內(nèi)存泄漏。

第 2 種情況：使用 strace
strace 命令是一種強(qiáng)大的工具，它能夠顯示所有由用戶空間程序發(fā)出的系統(tǒng)調(diào)用。strace 顯示這些調(diào)用的參數(shù)并返回符號(hào)形式的值。strace 從內(nèi)核接收信息，而且不需要以任何特殊的方式來構(gòu)建內(nèi)核。將跟蹤信息發(fā)送到應(yīng)用程序及內(nèi)核開發(fā)者都很有用。在清單 6 中，分區(qū)的一種格式有錯(cuò)誤，清單顯示了 strace 的開頭部分，內(nèi)容是關(guān)于調(diào)出創(chuàng)建文件系統(tǒng)操作（mkfs）的。strace 確定哪個(gè)調(diào)用導(dǎo)致問題出現(xiàn)。

清單 6. mkfs 上 strace 的開頭部分
execve("/sbin/mkfs.jfs", ["mkfs.jfs", "-f", "/dev/test1"], &
...
open("/dev/test1", O_RDWR|O_LARGEFILE) = 4
stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0
ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument)
write(2, "mkfs.jfs: warning - cannot setb" ..., 98mkfs.jfs: warning -
cannot set blocksize on block device /dev/test1: Invalid argument )
= 98
stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0
open("/dev/test1", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument)
write(2, "mkfs.jfs: can\'t determine device"..., ..._exit(1)
= ?

清單 6 顯示 ioctl 調(diào)用導(dǎo)致用來格式化分區(qū)的 mkfs 程序失敗。ioctl BLKGETSIZE64 失敗。（BLKGET-SIZE64 在調(diào)用 ioctl 的源代碼中定義。) BLKGETSIZE64 ioctl 將被添加到 Linux 中所有的設(shè)備，而在這里，邏輯卷管理器還不支持它。因此，如果 BLKGETSIZE64 ioctl 調(diào)用失敗，mkfs 代碼將改為調(diào)用較早的 ioctl 調(diào)用；這使得 mkfs 適用于邏輯卷管理器。

第 3 種情況：使用 gdb 和 Oops
您可以從命令行使用 gdb 程序（Free Software Foundation 的調(diào)試器）來找出錯(cuò)誤，也可以從諸如 Data Display Debugger（DDD）這樣的幾個(gè)圖形工具之一使用 gdb 程序來找出錯(cuò)誤。您可以使用 gdb 來調(diào)試用戶空間程序或 Linux 內(nèi)核。這一部分只討論從命令行運(yùn)行 gdb 的情況。

使用 gdb program name 命令啟動(dòng) gdb。gdb 將載入可執(zhí)行程序符號(hào)并顯示輸入提示符，讓您可以開始使用調(diào)試器。您可以通過三種方式用 gdb 查看進(jìn)程：

使用 attach 命令開始查看一個(gè)已經(jīng)運(yùn)行的進(jìn)程；attach 將停止進(jìn)程。

使用 run 命令執(zhí)行程序并從頭開始調(diào)試程序。

查看已有的核心文件來確定進(jìn)程終止時(shí)的狀態(tài)。要查看核心文件，請(qǐng)用下面的命令啟動(dòng) gdb。
gdb programname corefilename
要用核心文件進(jìn)行調(diào)試，您不僅需要程序的可執(zhí)行文件和源文件，還需要核心文件本身。要用核心文件啟動(dòng) gdb，請(qǐng)使用 -c 選項(xiàng)：

gdb -c core programname

gdb 顯示哪行代碼導(dǎo)致程序發(fā)生核心轉(zhuǎn)儲(chǔ)。

在運(yùn)行程序或連接到已經(jīng)運(yùn)行的程序之前，請(qǐng)列出您覺得有錯(cuò)誤的源代碼，設(shè)置斷點(diǎn)，然后開始調(diào)試程序。您可以使用 help 命令查看全面的 gdb 在線幫助和詳細(xì)的教程。

kgdb
kgdb 程序（使用 gdb 的遠(yuǎn)程主機(jī) Linux 內(nèi)核調(diào)試器）提供了一種使用 gdb 調(diào)試 Linux 內(nèi)核的機(jī)制。kgdb 程序是內(nèi)核的擴(kuò)展，它讓您能夠在遠(yuǎn)程主機(jī)上運(yùn)行 gdb 時(shí)連接到運(yùn)行用 kgdb 擴(kuò)展的內(nèi)核機(jī)器。您可以接著深入到內(nèi)核中、設(shè)置斷點(diǎn)、檢查數(shù)據(jù)并進(jìn)行其它操作（類似于您在應(yīng)用程序上使用 gdb 的方式）。這個(gè)補(bǔ)丁的主要特點(diǎn)之一就是運(yùn)行 gdb 的主機(jī)在引導(dǎo)過程中連接到目標(biāo)機(jī)器（運(yùn)行要被調(diào)試的內(nèi)核）。這讓您能夠盡早開始調(diào)試。請(qǐng)注意，補(bǔ)丁為 Linux 內(nèi)核添加了功能，所以 gdb 可以用來調(diào)試 Linux 內(nèi)核。

使用 kgdb 需要兩臺(tái)機(jī)器：一臺(tái)是開發(fā)機(jī)器，另一臺(tái)是測(cè)試機(jī)器。一條串行線（空調(diào)制解調(diào)器電纜）將通過機(jī)器的串口連接它們。您希望調(diào)試的內(nèi)核在測(cè)試機(jī)器上運(yùn)行；gdb 在開發(fā)機(jī)器上運(yùn)行。gdb 使用串行線與您要調(diào)試的內(nèi)核通信。

請(qǐng)遵循下面的步驟來設(shè)置 kgdb 調(diào)試環(huán)境：

下載您的 Linux 內(nèi)核版本適用的補(bǔ)丁。

將組件構(gòu)建到內(nèi)核，因?yàn)檫@是使用 kgdb 最簡單的方法。（請(qǐng)注意，有兩種方法可以構(gòu)建多數(shù)內(nèi)核組件，比如作為模塊或直接構(gòu)建到內(nèi)核中。舉例來說，日志紀(jì)錄文件系統(tǒng)（Journaled File System，JFS）可以作為模塊構(gòu)建，或直接構(gòu)建到內(nèi)核中。通過使用 gdb 補(bǔ)丁，我們就可以將 JFS 直接構(gòu)建到內(nèi)核中。）

應(yīng)用內(nèi)核補(bǔ)丁并重新構(gòu)建內(nèi)核。

創(chuàng)建一個(gè)名為 .gdbinit 的文件，并將其保存在內(nèi)核源文件子目錄中（換句話說就是 /usr/src/linux）。文件 .gdbinit 中有下面四行代碼：
set remotebaud 115200
symbol-file vmlinux
target remote /dev/ttyS0
set output-radix 16

將 append=gdb 這一行添加到 lilo，lilo 是用來在引導(dǎo)內(nèi)核時(shí)選擇使用哪個(gè)內(nèi)核的引導(dǎo)載入程序。
image=/boot/bzImage-2.4.17
label=gdb2417
read-only
root=/dev/sda8
append="gdb gdbttyS=1 gdb-baud=115200 nmi_watchdog=0"

清單 7 是一個(gè)腳本示例，它將您在開發(fā)機(jī)器上構(gòu)建的內(nèi)核和模塊引入測(cè)試機(jī)器。您需要修改下面幾項(xiàng)：

best@sfb：用戶標(biāo)識(shí)和機(jī)器名。
/usr/src/linux-2.4.17：內(nèi)核源代碼樹的目錄。
bzImage-2.4.17：測(cè)試機(jī)器上將引導(dǎo)的內(nèi)核名。
rcp 和 rsync：必須允許它在構(gòu)建內(nèi)核的機(jī)器上運(yùn)行。

清單 7. 引入測(cè)試機(jī)器的內(nèi)核和模塊的腳本
set -x
rcp best@sfb: /usr/src/linux-2.4.17/arch/i386/boot/bzImage /boot/bzImage-2.4.17
rcp best@sfb:/usr/src/linux-2.4.17/System.map /boot/System.map-2.4.17
rm -rf /lib/modules/2.4.17
rsync -a best@sfb:/lib/modules/2.4.17 /lib/modules
chown -R root /lib/modules/2.4.17
lilo

現(xiàn)在我們可以通過改為使用內(nèi)核源代碼樹開始的目錄來啟動(dòng)開發(fā)機(jī)器上的 gdb 程序了。在本示例中，內(nèi)核源代碼樹位于 /usr/src/linux-2.4.17。輸入 gdb 啟動(dòng)程序。

如果一切正常，測(cè)試機(jī)器將在啟動(dòng)過程中停止。輸入 gdb 命令 cont 以繼續(xù)啟動(dòng)過程。一個(gè)常見的問題是，空調(diào)制解調(diào)器電纜可能會(huì)被連接到錯(cuò)誤的串口。如果 gdb 不啟動(dòng)，將端口改為第二個(gè)串口，這會(huì)使 gdb 啟動(dòng)。

使用 kgdb 調(diào)試內(nèi)核問題
清單 8 列出了 jfs_mount.c 文件的源代碼中被修改過的代碼，我們?cè)诖a中創(chuàng)建了一個(gè)空指針異常，從而使代碼在第 109 行產(chǎn)生段錯(cuò)誤。

清單 8. 修改過后的 jfs_mount.c 代碼
int jfs_mount(struct super_block *sb)
{
...
int ptr; /* line 1 added */
jFYI(1, ("\nMount JFS\n"));
/ *
* read/validate superblock
* (initialize mount inode from the superblock)
* /
if ((rc = chkSuper(sb))) {
goto errout20;
}
108 ptr=0; /* line 2 added */
109 printk("%d\n",*ptr); /* line 3 added */

清單 9 在向文件系統(tǒng)發(fā)出 mount 命令之后顯示一個(gè) gdb 異常。kgdb 提供了幾條命令，如顯示數(shù)據(jù)結(jié)構(gòu)和變量值以及顯示系統(tǒng)中的所有任務(wù)處于什么狀態(tài)、它們駐留在何處、它們?cè)谀男┑胤绞褂昧?CPU 等等。清單 9 將顯示回溯跟蹤為該問題提供的信息；where 命令用來執(zhí)行反跟蹤，它將告訴被執(zhí)行的調(diào)用在代碼中的什么地方停止。

清單 9. gdb 異常和反跟蹤
mount -t jfs /dev/sdb /jfs

Program received signal SIGSEGV, Segmentation fault.
jfs_mount (sb=0xf78a3800) at jfs_mount.c:109
109 printk("%d\n",*ptr);
(gdb)where
#0 jfs_mount (sb=0xf78a3800) at jfs_mount.c:109
#1 0xc01a0dbb in jfs_read_super ... at super.c:280
#2 0xc0149ff5 in get_sb_bdev ... at super.c:620
#3 0xc014a89f in do_kern_mount ... at super.c:849
#4 0xc0160e66 in do_add_mount ... at namespace.c:569
#5 0xc01610f4 in do_mount ... at namespace.c:683
#6 0xc01611ea in sys_mount ... at namespace.c:716
#7 0xc01074a7 in system_call () at af_packet.c:1891
#8 0x0 in ?? ()
(gdb)

下一部分還將討論這個(gè)相同的 JFS 段錯(cuò)誤問題，但不設(shè)置調(diào)試器，如果您在非 kgdb 內(nèi)核環(huán)境中執(zhí)行清單 8 中的代碼，那么它使用內(nèi)核可能生成的 Oops 消息。

Oops 分析
Oops （也稱 panic，慌張）消息包含系統(tǒng)錯(cuò)誤的細(xì)節(jié)，如 CPU 寄存器的內(nèi)容。在 Linux 中，調(diào)試系統(tǒng)崩潰的傳統(tǒng)方法是分析在發(fā)生崩潰時(shí)發(fā)送到系統(tǒng)控制臺(tái)的 Oops 消息。一旦您掌握了細(xì)節(jié)，就可以將消息發(fā)送到 ksymoops 實(shí)用程序，它將試圖將代碼轉(zhuǎn)換為指令并將堆棧值映射到內(nèi)核符號(hào)。在很多情況下，這些信息就足夠您確定錯(cuò)誤的可能原因是什么了。請(qǐng)注意，Oops 消息并不包括核心文件。

讓我們假設(shè)系統(tǒng)剛剛創(chuàng)建了一條 Oops 消息。作為編寫代碼的人，您希望解決問題并確定什么導(dǎo)致了 Oops 消息的產(chǎn)生，或者您希望向顯示了 Oops 消息的代碼的開發(fā)者提供有關(guān)您的問題的大部分信息，從而及時(shí)地解決問題。Oops 消息是等式的一部分，但如果不通過 ksymoops 程序運(yùn)行它也于事無補(bǔ)。下面的圖顯示了格式化 Oops 消息的過程。

格式化 Oops 消息

ksymoops 需要幾項(xiàng)內(nèi)容：Oops 消息輸出、來自正在運(yùn)行的內(nèi)核的 System.map 文件，還有 /proc/ksyms、vmlinux 和 /proc/modules。關(guān)于如何使用 ksymoops，內(nèi)核源代碼 /usr/src/linux/Documentation/oops-tracing.txt 中或 ksymoops 手冊(cè)頁上有完整的說明可以參考。Ksymoops 反匯編代碼部分，指出發(fā)生錯(cuò)誤的指令，并顯示一個(gè)跟蹤部分表明代碼如何被調(diào)用。

首先，將 Oops 消息保存在一個(gè)文件中以便通過 ksymoops 實(shí)用程序運(yùn)行它。清單 10 顯示了由安裝 JFS 文件系統(tǒng)的 mount 命令創(chuàng)建的 Oops 消息，問題是由清單 8 中添加到 JFS 安裝代碼的那三行代碼產(chǎn)生的。

清單 10. ksymoops 處理后的 Oops 消息
ksymoops 2.4.0 on i686 2.4.17. Options used
... 15:59:37 sfb1 kernel: Unable to handle kernel NULL pointer dereference at
virtual address 0000000
... 15:59:37 sfb1 kernel: c01588fc
... 15:59:37 sfb1 kernel: *pde = 0000000
... 15:59:37 sfb1 kernel: Oops: 0000
... 15:59:37 sfb1 kernel: CPU:   0
... 15:59:37 sfb1 kernel: EIP:   0010:[jfs_mount+60/704]

... 15:59:37 sfb1 kernel: Call Trace: [jfs_read_super+287/688]
[get_sb_bdev+563/736] [do_kern_mount+189/336] [do_add_mount+35/208]
[do_page_fault+0/1264]
... 15:59:37 sfb1 kernel: Call Trace: []...
... 15:59:37 sfb1 kernel: [>EIP; c01588fc <=====
...
Trace; c0106cf3
Code; c01588fc
00000000 <_EIP>:
Code; c01588fc   <=====
0: 8b 2d 00 00 00 00 mov 0x0,%ebp   <=====
Code; c0158902
6: 55 push %ebp

接下來，您要確定 jfs_mount 中的哪一行代碼引起了這個(gè)問題。Oops 消息告訴我們問題是由位于偏移地址 3c 的指令引起的。做這件事的辦法之一是對(duì) jfs_mount.o 文件使用 objdump 實(shí)用程序，然后查看偏移地址 3c。Objdump 用來反匯編模塊函數(shù)，看看您的 C 源代碼會(huì)產(chǎn)生什么匯編指令。清單 11 顯示了使用 objdump 后您將看到的內(nèi)容，接著，我們查看 jfs_mount 的 C 代碼，可以看到空值是第 109 行引起的。偏移地址 3c 之所以很重要，是因?yàn)?Oops 消息將該處標(biāo)識(shí)為引起問題的位置。

清單 11. jfs_mount 的匯編程序清單
109 printk("%d\n",*ptr);

objdump jfs_mount.o

jfs_mount.o: file format elf32-i386

Disassembly of section .text:

00000000 :
0:55 push %ebp
...
2c: e8 cf 03 00 00   call   400
31: 89 c3     mov   %eax,%ebx
33: 58   pop   %eax
34: 85 db     test %ebx,%ebx
36: 0f 85 55 02 00 00 jne 291
3c: 8b 2d 00 00 00 00 mov 0x0,%ebp << problem line above
42: 55 push %ebp

kdb
Linux 內(nèi)核調(diào)試器（Linux kernel debugger，kdb）是 Linux 內(nèi)核的補(bǔ)丁，它提供了一種在系統(tǒng)能運(yùn)行時(shí)對(duì)內(nèi)核內(nèi)存和數(shù)據(jù)結(jié)構(gòu)進(jìn)行檢查的辦法。請(qǐng)注意，kdb 不需要兩臺(tái)機(jī)器，不過它也不允許您像 kgdb 那樣進(jìn)行源代碼級(jí)別上的調(diào)試。您可以添加額外的命令，給出該數(shù)據(jù)結(jié)構(gòu)的標(biāo)識(shí)或地址，這些命令便可以格式化和顯示基本的系統(tǒng)數(shù)據(jù)結(jié)構(gòu)。目前的命令集允許您控制包括以下操作在內(nèi)的內(nèi)核操作：

處理器單步執(zhí)行
執(zhí)行到某條特定指令時(shí)停止
當(dāng)存取（或修改）某個(gè)特定的虛擬內(nèi)存位置時(shí)停止
當(dāng)存取輸入／輸出地址空間中的寄存器時(shí)停止
對(duì)當(dāng)前活動(dòng)的任務(wù)和所有其它任務(wù)進(jìn)行堆棧回溯跟蹤（通過進(jìn)程 ID）
對(duì)指令進(jìn)行反匯編

追擊內(nèi)存溢出

您肯定不想陷入類似在幾千次調(diào)用之后發(fā)生分配溢出這樣的情形。

我們的小組花了許許多多時(shí)間來跟蹤稀奇古怪的內(nèi)存錯(cuò)誤問題。應(yīng)用程序在我們的開發(fā)工作站上能運(yùn)行，但在新的產(chǎn)品工作站上，這個(gè)應(yīng)用程序在調(diào)用 malloc() 兩百萬次之后就不能運(yùn)行了。真正的問題是在大約一百萬次調(diào)用之后發(fā)生了溢出。新系統(tǒng)之所有存在這個(gè)問題，是因?yàn)楸槐Ａ舻? malloc() 區(qū)域的布局有所不同，從而這些零散內(nèi)存被放置在了不同的地方，在發(fā)生溢出時(shí)破壞了一些不同的內(nèi)容。

我們用多種不同技術(shù) 來解決這個(gè)問題，其中一種是使用調(diào)試器，另一種是在源代碼中添加跟蹤功能。在我職業(yè)生涯的大概也是這個(gè)時(shí)候，我便開始關(guān)注內(nèi)存調(diào)試工具，希望能更快更有效地解決這些類型的問題。在開始一個(gè)新項(xiàng)目時(shí)，我最先做的事情之一就是運(yùn)行 MEMWATCH 和 YAMD，看看它們是不是會(huì)指出內(nèi)存管理方面的問題。

內(nèi)存泄漏是應(yīng)用程序中常見的問題，不過您可以使用本文所講述的工具來解決這些問題。

第 4 種情況：使用魔術(shù)鍵控順序進(jìn)行回溯跟蹤
如果在 Linux 掛起時(shí)您的鍵盤仍然能用，那請(qǐng)您使用以下方法來幫助解決掛起問題的根源。遵循這些步驟，您便可以顯示當(dāng)前運(yùn)行的進(jìn)程和所有使用魔術(shù)鍵控順序的進(jìn)程的回溯跟蹤。

您正在運(yùn)行的內(nèi)核必須是在啟用 CONFIG_MAGIC_SYS-REQ 的情況下構(gòu)建的。您還必須處在文本模式。CLTR+ALT+F1 會(huì)使您進(jìn)入文本模式，CLTR+ALT+F7 會(huì)使您回到 X Windows。
當(dāng)在文本模式時(shí)，請(qǐng)按，然后按。上述魔術(shù)的擊鍵會(huì)分別給出當(dāng)前運(yùn)行的進(jìn)程和所有進(jìn)程的堆棧跟蹤。
請(qǐng)查找 /var/log/messages。如果一切設(shè)置正確，則系統(tǒng)應(yīng)該已經(jīng)為您轉(zhuǎn)換了內(nèi)核的符號(hào)地址。回溯跟蹤將被寫到 /var/log/messages 文件中。

結(jié)束語
幫助調(diào)試 Linux 上的程序有許多不同的工具可供使用。本文講述的工具可以幫助您解決許多編碼問題。能顯示內(nèi)存泄漏、溢出等等的位置的工具可以解決內(nèi)存管理問題，我發(fā)現(xiàn) MEMWATCH 和 YAMD 很有幫助。

使用 Linux 內(nèi)核補(bǔ)丁會(huì)使 gdb 能在 Linux 內(nèi)核上工作，這對(duì)解決我工作中使用的 Linux 的文件系統(tǒng)方面的問題很有幫助。此外，跟蹤實(shí)用程序能幫助確定在系統(tǒng)調(diào)用期間文件系統(tǒng)實(shí)用程序什么地方出了故障。下次當(dāng)您要擺平 Linux 中的錯(cuò)誤時(shí)，請(qǐng)?jiān)囋囘@些工具中的某一個(gè)。

posted on 2008-03-14 13:58 隨意門閱讀(244) 評(píng)論(0) 編輯收藏引用

只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
【推薦】100%開源！大型工業(yè)跨平臺(tái)軟件C++源碼提供，建模，組態(tài)！



網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

興海北路