基于c語言中調試工具的用法匯總(不包含gdb)

2020-01-26 16:14:28

字體：大中小

來源：轉載

供稿：網友

是不是只有編譯的時候才知道程序寫了錯誤?有沒有在未編譯的時候就讓機器幫你檢查錯誤的工具呢?
答案是:有!!

splint工具.用一個最簡單的HELLO WORLD來表述:
=====================================

復制代碼代碼如下:

/*錯誤很明顯*/
#include <stdio.h>

int main(void)
{
print("hello world/n", s);
return
}

-----------------------------------------------------
casio$ splint -strict foo.c
Splint 3.1.1 --- 03 Nov 2006

foo.c: (in function main)
foo.c:5:2: Unrecognized identifier: print <-------找到print不是printf
Identifier used in code has not been declared. (Use -unrecog to inhibit
warning)
foo.c:5:25: Unrecognized identifier: s <-------未定義變量s
foo.c:5:2: Statement has no effect (possible undected modification through call
to unconstrained function print): print("hello wor... <---------不存在prinf函數
Statement has no visible effect --- no values are modified. It may modify
something through a call to an unconstrained function. (Use -noeffectuncon to
inhibit warning)
foo.c:7:2: Parse Error. (For help on parse errors, see splint -help <------對應return語法錯誤
parseerrors.)
*** Cannot continue.

=============================================

cxref

cxref程序分析C源代碼并且生成一個交叉引用。他顯示了每一個符號在程序中何處被提到。他使用標記星號的每一個符號定義位置生成一個排序列表，如下所示：

SYMBOL FILE FUNCTION LINE
BASENID prog.c ― *12 *96 124 126 146 156 166
BINSIZE prog.c ― *30 197 198 199 206
BUFMAX prog.c ― *44 45 90
BUFSIZ /usr/include/stdio.h ― *4
EOF /usr/include/stdio.h ― *27
argc prog.c ― 36
prog.c main *37 61 81
argv prog.c ― 36
prog.c main *38 61
calldata prog.c ― *5
prog.c main 64 188
calls prog.c ― *19
prog.c main 54

在作者的機子上，前面的輸入在程序的源碼目錄中使用下面的命令來生成的：

$ cxref *.c *.h

但是實際的語法因為版本的不同而不同。查看我們系統的文檔或是man手冊可以得到更多的信息。

cflow <使用時輸入cflow *.c就可以了.可以馬上搞清除什么函數調用了什么.>

cflow程序會輸出一個函數調用樹，這是一個顯示函數調用關系的圖表。這對于查看程序結構來了解他是如何操作的以及了解對于一個函數有哪些影響是十分有用的。一些版本的cflow可以同時作用于目標文件與源代碼。查看手冊頁我們可以了解更為詳細的操作。

下面是由一個cflow版本(cflow-2.0)所獲得的例子輸出，這個版本的cflow版本是由Marty Leisner維護的，并且可以網上得到。

1 file_ungetc {prcc.c 997}
2 main {prcc.c 70}
3 getopt {}
4 show_all_lists {prcc.c 1070}
5 display_list {prcc.c 1056}
6 printf {}
7 exit {}
8 exit {}
9 usage {prcc.c 59}
10 fprintf {}
11 exit {}

從這個輸出中我們可以看到main函數調用show_all_lists，而show_all_lists調用display_list，display_list本身調用printf。

這個版本cflow的一個選項就是-i，這會生成一個反轉的流程圖。對于每一個函數，cflow列出調用他的其他函數。這聽起來有些復雜，但是實際上并不是這樣。下面是一個例子。

19 display_list {prcc.c 1056}
20 show_all_lists {prcc.c 1070}
21 exit {}
22 main {prcc.c 70}
23 show_all_lists {prcc.c 1070}
24 usage {prcc.c 59}
...
74 printf {}
75 display_list {prcc.c 1056}
76 maketag {prcc.c 487}
77 show_all_lists {prcc.c 1070}
78 main {prcc.c 70}
...
99 usage {prcc.c 59}
100 main {prcc.c 70}

例如，這告訴我們調用exit的函數有main，show_all_lists與usage。

使用prof/gprof執行性能測試

當我們試著追蹤一個程序的性能問題時一個十分有用的技術就是執行性能測試(execution profiling)。通常被特殊的編譯器選項以及輔助程序所支持，一個程序的性能顯示他在哪里花費時間。

prof程序（以及其GNU版本gprof）會由性能測試程序運行時所生成的執行追蹤文件中輸出報告。一個可執行的性能測試是由指定-p選項（對prof）或是-pg選項（對gprof）所生成的：

$ cc -pg -o program program.c

這個程序是使用一個特殊版本的C庫進行鏈接的并且被修改來包含監視代碼。對于不同的系統結果也許不同，但是通常是由安排頻繁被中斷的程序以及記錄執行位置來做到的。監視數據被寫入當前目錄中的一個文件，mon.out（對于gprof為gmon.out）。

$ ./program
$ ls -ls
2 -rw-r--r-- 1 neil users 1294 Feb 4 11:48 gmon.out

然后用命令:gprof ./program可以查看到下面的報告

prof/gprof程序讀取這些監視數據并且生成一個報告。查看其手冊頁可以詳細了解其程序選項。下面以gprof輸出作為一個例子：

cumulative self self total
time seconds seconds calls ms/call ms/call name
18.5 0.10 0.10 8664 0.01 0.03 _doscan [4]
18.5 0.20 0.10 mcount (60)
14.8 0.28 0.08 43320 0.00 0.00 _number [5]
9.3 0.33 0.05 8664 0.01 0.01 _format_arg [6]
7.4 0.37 0.04 112632 0.00 0.00 _ungetc [8]
7.4 0.41 0.04 8757 0.00 0.00 _memccpy [9]
7.4 0.45 0.04 1 40.00 390.02 _main [2]
3.7 0.47 0.02 53 0.38 0.38 _read [12]
3.7 0.49 0.02 w4str [10]
1.9 0.50 0.01 26034 0.00 0.00 _strlen [16]
1.9 0.51 0.01 8664 0.00 0.00 strncmp [17]

內存調試

富含bug而且難于跟蹤調試的一個區域就是動態內存分配。如果我們編譯一個使用malloc與free來分配內存的程序，很重要的一點就是我們要跟蹤我們所分配的內存塊，并且保證不要使用已經釋放的內存塊。

通常，內存是由malloc分配并且賦給一個指針變量的。如果指針變量被修改了，而又沒有其他的指針來指向這個內存塊，他就會變為不可訪問的內存塊。這就是一個內存泄露，而且會使得我們程序尺寸變大。如果我們泄露了大量的內存，那么我們的系統就會變慢并且會最終用盡內存。

如果我們在超出一個分配的內存塊的結束部分（或是在一個內存塊的開始部分）寫入數據，我們很有可能會破壞malloc庫來跟蹤分配所用的數據結構。在這種情況下，在將來的某個時刻，調用malloc，或者甚至是free，就會引起段錯誤，而我們的程序就會崩潰。跟蹤錯誤發生的精確點是非常困難的，因為很可能他在引起崩潰的事件發生以前很一段時間就已經發生了。

不必奇怪的是，有一些工具，商業或是自由的，可以有助于處理這兩種問題類型。例如，有許多不同的malloc與free版本，其中的一些包含額外的代碼在分配與回收上進行檢測嘗試檢測一個內存塊被釋放兩次或是其他一些濫用類型的情況。

ElectricFence

ElectricFence 庫是由Bruce Perens開發的，并且在一些Linux發行版本中作為一個可選的組件來提供，例如RedHat，而且已經可以在網絡上獲得。他嘗試使用Linux的虛擬內存工具來保護malloc與free所使用的內存，從而在內存被破壞時終止程序。

試驗－－ElectricFence

下面的程序，efence.c，使用malloc分配一個內存塊，然后在超出塊結束處寫入數據。讓我們看一下會發生什么情況。

復制代碼代碼如下:

#include <stdio.h>
#include <stdlib.h>
int main()
{
   char *ptr = (char *) malloc(1024);
   ptr[0] = 0;
   /* Now write beyond the block */
   ptr[1024] = 0;/*寫非法*/
   exit(0);
}

當我們編譯運行這個程序時，我們并不會看到進一步的行為。然而，似乎malloc所分配的內存區域有一些問題，而我們實際上已經遇到了麻煩。

$ cc -o efence efence.c
$ ./efence
$

然而，如果我們使用ElectricFence庫，libefence.a來鏈接這個程序，我們就會得到一個即時的響應。

$ cc -o efence efence.c -lefence
$ ./efence
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Segmentation fault
$

在調試器下運行可以定位這個問題：

$ cc -g -o efence efence.c -lefence
$ gdb efence
(gdb) run
Starting program: /home/neil/BLP3/chapter10/efence
[New Thread 1024 (LWP 1869)]
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1869)]
0x080484ad in main () at efence.c:10
10 ptr[1024] = 0;
(gdb)

工作原理

Electric替換malloc并且將函數與計算機處理器的虛擬內存特性相關聯來阻止非法的內存訪問。當這樣的訪問發生時，就會拋出一個段錯誤信息從而可以終止程序。

valgrind

valgrind是一個可以檢測我們已經討論過的許多問題的工具。事實上，他可以檢測數據訪問錯誤與內存泄露。也許他并沒有被包含在我們的Linux發行版本中，但是我們可以在http://developer.kde.org/~sewardj處得到。

程序并不需要使用valgrind重新編譯，而我們甚至可以調用一個正在運行的程序的內存訪問。他很值得一看，他已經用在主要的開發上，包含KDE版本3。

試驗－－valgrind

下面的程序，checker.c，分配一些內存，讀取超過那塊內存限制的位置，在其結束處之外寫入數據，然后使其不能訪問。

復制代碼代碼如下:

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
   char *ptr = (char *) malloc(1024);
   char ch;
   /* Uninitialized read */
   ch = ptr[1024];/*讀非法*/
   /* Write beyond the block */
   ptr[1024] = 0;/*寫非法*/
   /* Orphan the block */
   ptr = 0;/*野指針*/
   exit(0);
}

要使用valgrind，我們只需要簡單的運行valgrind命令，傳遞我們希望檢測的選項，其后是使用其參數運行的程序。

當我們使用valgrind來運行我們的程序時，我們可以看到診斷出許多問題：

$ valgrind --leak-check=yes -v ./checker
==3436== valgrind-1.0.4, a memory error detector for x86 GNU/Linux.
==3436== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==3436== Estimated CPU clock rate is 452 MHz
==3436== For more details, rerun with: -v
==3436==
==3436== Invalid read of size 1
==3436== at 0x8048397: main (checker.c:10)
==3436== by 0x402574F2: __libc_start_main (in /lib/libc.so.6)
==3436== by 0x80482D1: exit@@GLIBC_2.0 (in /home/neil/BLP3/chapter10/checker)
==3436== Address 0x42AD1424 is 0 bytes after a block of size 1024 alloc'd
==3436== at 0x4003CA75: malloc (vg_clientfuncs.c:100)
==3436== by 0x8048389: main (checker.c:6)
==3436== by 0x402574F2: __libc_start_main (in /lib/libc.so.6)
==3436== by 0x80482D1: exit@@GLIBC_2.0 (in /home/neil/BLP3/chapter10/checker)
==3436==
==3436== Invalid write of size 1
==3436== at 0x80483A4: main (checker.c:13)
==3436== by 0x402574F2: __libc_start_main (in /lib/libc.so.6)
==3436== by 0x80482D1: exit@@GLIBC_2.0 (in /home/neil/BLP3/chapter10/checker)
==3436== Address 0x42AD1424 is 0 bytes after a block of size 1024 alloc'd
==3436== at 0x4003CA75: malloc (vg_clientfuncs.c:100)
==3436== by 0x8048389: main (checker.c:6)
==3436== by 0x402574F2: __libc_start_main (in /lib/libc.so.6)
==3436== by 0x80482D1: exit@@GLIBC_2.0 (in /home/neil/BLP3/chapter10/checker)
==3436==
==3436== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==3436== malloc/free: in use at exit: 1024 bytes in 1 blocks.
==3436== malloc/free: 1 allocs, 0 frees, 1024 bytes allocated.
==3436== For counts of detected errors, rerun with: -v
==3436== searching for pointers to 1 not-freed blocks.
==3436== checked 3468724 bytes.
==3436==
==3436== definitely lost: 1024 bytes in 1 blocks.
==3436== possibly lost: 0 bytes in 0 blocks.
==3436== still reachable: 0 bytes in 0 blocks.
==3436==
==3436== 1024 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3436== at 0x4003CA75: malloc (vg_clientfuncs.c:100)
==3436== by 0x8048389: main (checker.c:6)
==3436== by 0x402574F2: __libc_start_main (in /lib/libc.so.6)
==3436== by 0x80482D1: exit@@GLIBC_2.0 (in /home/neil/BLP3/chapter10/checker)
==3436==
==3436== LEAK SUMMARY:
==3436== definitely lost: 1024 bytes in 1 blocks.
==3436== possibly lost: 0 bytes in 0 blocks.
==3436== still reachable: 0 bytes in 0 blocks.
==3436== Reachable blocks (those to which a pointer was found) are not shown.
==3436== To see them, rerun with: --show-reachable=yes
==3436== $