1. 在 compile 時加入 -g 的參數
如果要 debug 的是 compile 過的 program
最簡單的方式就是在 compile 的時候 加入 -g 的參數
這樣 compiler ( 如 gcc ) 就會在 compile 時，
加入給 debugger ( 如 gdb ) 用的資訊
接下來產生的執行檔就能很方便的讓我們來 debug

能夠用 gdb debug 的情況有..

1. 用 gdb 來跑 program
> gdb your_prog
然後在下 run
來跑程式，或設 breakpoint 等等
( 關於 gdb 的使用，請參照 reference )
2. 用 gdb 來 detach 正在跑的 program
> gdb your_program process_id
這個方法就是先查出你要查的 process id
然後用 gdb 把這個程式停下來
來檢查看看問題出在哪
3. 有時候有的程式因為一些因素 ( 如 memory access violation )
而造成 core dump ( 這個會在作業系統留下 xxx core dump 的 message )
通常會在程式執行的 dir 產生 xxx.core 的 core file
這時候我們也可以用
> gdb your_program core_file
來做 debug 的動作
4. 最後，我們可以用 gcore(1) 這個程式
把正在跑的程式在 memory 的 image 抓成一個 core file
再用 gdb 來觀察這個 core file
5. 另外，在程式沒有 compile with -g option 的情況下
我們還是很常用到 gdb 的一個方法是 backtrace 這個指令
這個可以用來觀察程式的 call stack。
可以知道程式卡/死在哪個 function call 內

2. 觀察和 process 有關的資訊

很多情況下，我們的程式不一定有加上 -g 的 debug 參數
這個時候，有一些比較能 locate 問題的 system utils 可以幫助我們

1. truss(1)
這個可以用來觀察某個 program 使用的 system call
比如說 open(), close() 等等
這個可以讓我們了解到這個 program 正在 access 哪些檔案
卡死在哪個地方
ex: > truss -p process_pid
2. fstat or sockstat
用 sockstat | grep process_pid
可以查到這個程式開的 local address/port 及 foreign address/port

最近因為某些需求，開始回頭用 Ubuntu/Debian

最近有人問我，有沒有辦法找出某個已安裝的套件名稱，或者找出某個檔案屬於哪個套件

前者可以用 dpkg 或 dlocate -S 來達到目的

不過後者我當時回答不上來

找了一下資料，apt-file 似乎是個不錯的 tool

安裝 apt-file
sudo apt-get install apt-file
更新 apt-file 的資料
sudo apt-file update
利用 apt-file 找出套件
sudo apt-file search gcc-3.4

還有許多有趣的玩法及組合，就慢慢參考 man manual 吧:p