strace編譯

⑴ php swoole 只能運行在php-cli 環境嗎

一直想寫點Swoole的東西，畢竟它重新定義了php，卻一直不知道怎麼下手寫Swoole涉及的知識點非常多，互為表裡，每次想寫都發現根本理不出一個頭緒Swoole是一個php的擴展，它的核心目的就是解決php在實現server服務中可能遇到的一系列問題，這些問題用源生的php往往並不能很高效（執行效率）的解決，一般也不會使用php來解決，所以會有說swolle重新定義的php的說法。
其實swoole也提供了一個框架，swoole framework是基於swoole extension設計的一個框架，要用好這個框架，還是要先了解swoole extension。
擴展的英文名稱是Extension，php擴展是用C語言作為開發語言，基於Zend引擎提供的API，編譯成的一個動態庫。
如果曾經做過類似動態庫調用開發的童鞋可能會更好理解一些，例如Android中的NDK開發在php的配置文件中配置好extension的屬性後，就可以引用這個動態庫了。
也就是說，swoole本身是用C語言編寫的，它可以讓php獲得一些額外的function。
然後是運行方式，swoole的許多功能都只能運行在cli模式下，而cli模式往往是很多剛接觸swoole的phper遇到的第一個問題。
有時候其實只是需要轉變一下思路
我們現在整理一下最常見的php代碼執行方式：
安裝apache、php
配置apache對那個目錄進行php解析
用瀏覽器訪問那個目錄的php文件
更多的細節這里就不提了，畢竟我相信每個phper對這個都是很熟悉的。
但這里就開始出現了第一個問題，我們知道，php是一個腳本語言，腳本語言的核心特點在於不用編譯，隨時執行，而執行腳本的工具就是解析器，而php的解析器就是zend引擎。
嚴格來說，zend並不是唯一的選擇，不過，zend是最官方的。另外，Zend Studio和Zend Engine不是同一個東西，本文中的Zend全部指Zend Engine。
換個角度講，只要有解析器，寫好的php腳本就是可以執行的，而zend引擎與apache之間並沒有絕對的關系實際上，apahce是調用了zend對php腳本進行執行，然後將執行結果輸出給了瀏覽器所以所謂cli模式（CommandLine，命令行模式），其實就是在命令行下直接調用zend引擎對php腳本進行解析並執行，並獲得程序輸出結果的php腳本執行方式。
其實php也可以作為shell腳本來使用哦，就像bash shell一樣既然問題講清楚了，在一個系統中具體怎麼操作呢？
本文以CentOS 7.5作為系統環境，swoole是針對linux系統開發的，windows下並不適用。學習swoole的一個前題是懂得基本的linux系統使用。
當安裝好php的時候，找到php的安裝目錄，如果是默認安裝的話，可以試試whereis命令# 某種簡單的方法
whereis php
> /usr/local/bin/php;
locate whereis find這些命令都可以試試，目的是找到php然後我們來寫一個最經典的php腳本：
<?php
//vi hello_cli.php
echo 'Hello PHP Cli';
編寫純php腳本時，php標簽不要封口
然後我們在shell里執行它：
/usr/local/bin/php hello_cli.php
> Hello PHP Cli
這段代碼中的第一個php，是一個可執行文件，它接受一個php腳本文件作為輸入參數，並解析執行這個php腳本文件（通過zend）。
沒有錯，第一個cli模式下的php程序就被你執行成功了！
默認情況下，php都會被安裝在了$PATH的目錄下，那就可以直接省略路徑前綴了，下文中調用php的時候，全都省略了路徑前綴。
因為swoole是pecl的項目，所以使用pecl安裝是最簡單的方法，強烈推薦第一次接觸的童鞋先使用pecl安裝，在熟悉了swoole之後，再考慮使用編譯安裝的方式以獲取更多進階功能。
pecl這個工具基本都會被安裝在與php相同的目錄下（往往也都是$PATH目錄）pecl install swoole
執行以下命令查看是否安裝成功：
php -m | grep swoole
> swoole
如果正確的輸出了swoole，那麼恭喜你，這次安裝很成功另一個常見的比較麻煩的問題是，有些童鞋的電腦里安裝了多個php，而安裝的時候沒有正確的安裝到預期的php的擴展目錄中，就會導致無法正常工作，解決方案就是弄清楚各個php安裝目錄及配置關系，選擇正確的目錄進行安裝。
其實本文還沒正式開始介紹swoole，都是在學習swoole之前的准備工作，swoole的上手門檻比一般的php應用要高的多，如果沒有網路開發和操作系統方面的一些知識，學習它並不是一件容易的事情，學習曲線很陡峭。
這句話我在群里說了無數次
很多新手會詬病swoole的手冊寫的太模糊，其實是前置知識不足，而手冊也給出了需要的前置知識列表，以下引用至官網的手冊-學習swoole需要哪些知識？
多進程/多線程
了解Linux操作系統進程和線程的概念
了解Linux進程/線程切換調度的基本知識
了解進程間通信的基本知識，如管道、UnixSocket、消息隊列、共享內存socket
了解SOCKET的基本操作如accept/connect、send/recv、close、listen、bind了解SOCKET的接收緩存區、發送緩存區、阻塞/非阻塞、超時等概念IO復用
了解select/poll/epoll
了解基於select/epoll實現的事件循環，Reactor模型了解可讀事件、可寫事件
TCP/IP網路協議
了解TCP/IP協議
了解TCP、UDP傳輸協議
調試工具
使用gdb調試Linux程序
使用strace跟蹤進程的系統調用
使用tcpmp跟蹤網路通信過程
其他Linux系統工具，如ps、lsof、top、vmstat、netstat、sar、ss等學習並理解一個新事務並不是一個容易的事情，特別對於swoole這種具備一定顛覆性的工具，要有耐心和實踐。
淡定的把手冊看完，遇到不理解的名詞學會使用搜索引擎學習，swoole的手冊其實是個大寶庫，網路開發常見的問題其實里邊都涉及到了。

⑵ 如何根據 strace可執行程序的調試信息定位源碼出錯位置

跟蹤程式執行時的系統調用和所接收的信號.通常的用法是strace執行一直到commande結束,並且將所調用的系統調用的名稱、參數和返回值輸出到標准輸出或者輸出到-o指定的文件.
strace是一個功能強大的調試,分析診斷工具,你將發現在你要調試一個無法看到源碼或者源碼無法在編譯的程序時是一個極好的幫手.
你將輕松的學習到一個軟體是如何通過系統調用來實現他的功能的.而且作為一個程序設計師,你可以了解到在用戶態和內核態是如何通過系統調用和信號來實現程序的功能的.
strace的每一行輸出包括系統調用名稱,然後是參數和返回值.
strace是一個必不可少的調試工具，strace用來監視系統調用。你不僅可以調試一個新開始的程序，也可以調試一個已經在運行的程序（把strace綁定到一個已有的PID上面）。
strace不僅可以被程序員使用，普通系統管理員和用戶也可以使用strace來調試系統錯誤。必須承認，strace的輸出不總是容易理 解，但是很多輸出對大多數人來說是不重要的。你會慢慢學會從大量輸出中找到你可能需要的信息，像許可權錯誤，文件未找到之類的，那時strace就會成為一 個有力的工具了。

⑶ java編譯好了，小程序查看器窗口為什麼不出現

看代碼貌似沒問題 極可能是異常拋出 給下面異常捕捉加上printSackStrace看看

⑷ Linux主要是干什麼用的

主要是用於後端伺服器操作系統

Linux是一種自由和開放源碼的類UNIX操作系統。它能運行主要的Unix工具軟體、應用程序和網路協議，支持32位和64位硬體。該操作系統的內核由林納斯·托瓦茲於1991年10月5日首次發布。

Linux最初是作為支持英特爾x86架構的個人計算機的一個自由操作系統，現可運行在伺服器和其他大型平台之上，如大型計算機和超級計算機。Linux也廣泛應用在嵌入式系統上，如手機（Mobile Phone）、平板電腦（Tablet）、路由器（Router）、電視（TV）和電子游戲機等。

(4)strace編譯擴展閱讀：

2001年1月，Linux 2.4發布，它進一步地提升了SMP系統的擴展性，同時它也集成了很多用於支持桌面系統的特性：USB，PC卡(PCMCIA)的支持，內置的即插即用，等等功能。

2003年12月，Linux 2.6版內核發布，相對於2.4版內核2.6在對系統的支持都有很大的變化。

2004年的第1月，SuSE嫁到了Novell，SCO繼續頂著罵名四處強行「化緣」， Asianux， MandrakeSoft也在五年中首次宣布季度贏利。3月，SGI宣布成功實現了Linux操作系統支持256個Itanium 2處理器。

⑸ 調試驅動程序的高效方法

驅動程序開發的一個重大難點就是不易調試。本文目的就是介紹驅動開發中常用的幾種直接和間接的調試手段，它們是：
1、利用printk
2、查看OOP消息
3、利用strace
4、利用內核內置的hacking選項
5、利用ioctl方法
6、利用/proc 文件系統
7、使用kgdb
前兩種如下：
一、利用printk
這是驅動開發中最朴實無華，同時也是最常用和有效的手段。scull驅動的main.c第338行如下，就是使用printk進行調試的例子，這樣的例子相信大家在閱讀驅動源碼時隨處可見。
338 // printk(KERN_ALERT "wakeup by signal in process %d\n", current->pid);
printk的功能與我們經常在應用程序中使用的printf是一樣的，不同之處在於printk可以在列印字元串前面加上內核定義的宏，例如上面例子中的KERN_ALERT（注意：宏與字元串之間沒有逗號）。
#define KERN_EMERG "<0>"
#define KERN_ALERT "<1>"
#define KERN_CRIT "<2>"
#define KERN_ERR "<3>"
#define KERN_WARNING "<4>"
#define KERN_NOTICE "<5>"
#define KERN_INFO "<6>"
#define KERN_DEBUG "<7>"
#define DEFAULT_CONSOLE_LOGLEVEL 7


這個宏是用來定義需要列印的字元串的級別。值越小，級別越高。內核中有個參數用來控制是否將printk列印的字元串輸出到控制台（屏幕或者/sys/log/syslog日誌文件）
# cat /proc/sys/kernel/printk
6 4 1 7
第一個6表示級別高於（小於）6的消息才會被輸出到控制台，第二個4表示如果調用printk時沒有指定消息級別（宏）則消息的級別為4，第三個1表示接受的最高（最小）級別是1，第四個7表示系統啟動時第一個6原來的初值是7。
因此，如果你發現在控制台上看不到你程序中某些printk的輸出，請使用echo 8 > /proc/sys/kernel/printk來解決。
在復雜驅動的開發過程中，為了調試會在源碼中加入成百上千的printk語句。而當調試完畢形成最終產品的時候必然會將這些printk語句刪除想想驅動的使用者而不是開發者吧。記住：己所不欲，勿施於人），這個工作量是不小的。最要命的是，如果我們將調試用的printk語句刪除後，用戶又報告驅動有bug，所以我們又不得不手工將這些上千條的printk語句再重新加上。oh，my god，殺了我吧。所以，我們需要一種能方便地打開和關閉調試信息的手段。哪裡能找到這種手段呢？哈哈，遠在天邊，近在眼前。看看scull驅動或者leds驅動的源代碼吧！
#define LEDS_DEBUG
#undef PDEBUG
#ifdef LEDS_DEBUG
#ifdef __KERNEL__

#define PDEBUG(fmt, args…) printk( KERN_EMERG "leds: " fmt, ## args)
#else

#define PDEBUG(fmt, args…) fprintf(stderr, fmt, ## args)
#endif
#else
#define PDEBUG(fmt, args…)
#endif
#undef PDEBUGG
#define PDEBUGG(fmt, args…)
這樣一來，在開發驅動的過程中，如果想列印調試消息，我們就可以用PDEBUG("address of i_cdev is %p\n", inode->i_cdev);，如果不想看到該調試消息，就只需要簡單的將PDEBUG改為PDEBUGG即可。而當我們調試完畢形成最終產品時，只需要簡單地將第1行注釋掉即可。
上邊那一段代碼中的__KERNEL__是內核中定義的宏，當我們編譯內核（包括模塊）時，它會被定義。當然如果你不明白代碼中的…和##是什麼意思的話，就請認真查閱一下gcc關於預處理部分的資料吧！如果你實在太懶不願意去查閱的話，那就充當VC工程師把上面的代碼到你的代碼中去吧。
二、查看OOP消息
OOP意為驚訝。當你的驅動有問題，內核不驚訝才怪：嘿！小子，你干嗎亂來！好吧，就讓我們來看看內核是如何驚訝的。
根據faulty.c（單擊下載）編譯出faulty.ko，並 insmod faulty.ko。執行echo yang >/dev/faulty，結果內核就驚訝了。內核為什麼會驚訝呢？因為faulty驅動的write函數執行了*(int *)0 = 0，向內存0地址寫入，這是內核絕對不會容許的。
52 ssize_t faulty_write (struct file *filp, const char __user *buf, size_t count,
53 loff_t *pos)
54 {
55
56 *(int *)0 = 0;
57 return 0;
58 }
1 Unable to handle kernel NULL pointer dereference at virtual address 00000000
2 pgd = c3894000
3 [00000000] *pgd=33830031, *pte=00000000, *ppte=00000000
4 Internal error: Oops: 817 [#1] PREEMPT
5 Moles linked in: faulty scull
6 CPU: 0 Not tainted (2.6.22.6 #4)
7 PC is at faulty_write+0×10/0×18 [faulty]
8 LR is at vfs_write+0xc4/0×148
9 pc : [] lr : [] psr: a0000013
10 sp : c3871f44 ip : c3871f54 fp : c3871f50
11 r10: 4021765c r9 : c3870000 r8 : 00000000
12 r7 : 00000004 r6 : c3871f78 r5 : 40016000 r4 : c38e5160
13 r3 : c3871f78 r2 : 00000004 r1 : 40016000 r0 : 00000000
14 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user
15 Control: c000717f Table: 33894000 DAC: 00000015
16 Process sh (pid: 745, stack limit = 0xc3870258)
17 Stack: (0xc3871f44 to 0xc3872000)
18 1f40: c3871f74 c3871f54 c0088eb8 bf00608c 00000004 c38e5180 c38e5160
19 1f60: c3871f78 00000000 c3871fa4 c3871f78 c0088ffc c0088e04 00000000 00000000
20 1f80: 00000000 00000004 40016000 40215730 00000004 c002c0e4 00000000 c3871fa8
21 1fa0: c002bf40 c0088fc0 00000004 40016000 00000001 40016000 00000004 00000000
22 1fc0: 00000004 40016000 40215730 00000004 00000001 00000000 4021765c 00000000
23 1fe0: 00000000 bea60964 0000266c 401adb40 60000010 00000001 00000000 00000000
24 Backtrace:
25 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)
26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)
27 r7:00000000 r6:c3871f78 r5:c38e5160 r4:c38e5180
28 [] (sys_write+0×0/0×74) from [] (ret_fast_syscall+0×0/0x2c)
29 r8:c002c0e4 r7:00000004 r6:40215730 r5:40016000 r4:00000004
30 Code: e1a0c00d e92dd800 e24cb004 e3a00000 (e5800000)
1行驚訝的原因，也就是報告出錯的原因；
2-4行是OOP信息序號；
5行是出錯時內核已載入模塊；
6行是發生錯誤的CPU序號；
7-15行是發生錯誤的位置，以及當時CPU各個寄存器的值，這最有利於我們找出問題所在地；
16行是當前進程的名字及進程ID
17-23行是出錯時，棧內的內容
24-29行是棧回溯信息，可看出直到出錯時的函數遞進調用關系（確保CONFIG_FRAME_POINTER被定義）
30行是出錯指令及其附近指令的機器碼，出錯指令本身在小括弧中


反匯編faulty.ko（ arm-linux-objmp -D faulty.ko > faulty.dis ；cat faulty.dis）可以看到如下的語句如下：
0000007c :
7c: e1a0c00d mov ip, sp
80: e92dd800 stmdb sp!, {fp, ip, lr, pc}
84: e24cb004 sub fp, ip, #4 ; 0×4
88: e3a00000 mov r0, #0 ; 0×0
8c: e5800000 str r0, [r0]
90: e89da800 ldmia sp, {fp, sp, pc}
定位出錯位置以及獲取相關信息的過程：
9 pc : [] lr : [] psr: a0000013

25 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)
26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)
出錯代碼是faulty_write函數中的第5條指令（(0xbf00608c-0xbf00607c)/4+1=5），該函數的首地址是0xbf00607c，該函數總共6條指令（0×18），該函數是被0xc0088eb8的前一條指令調用的（即：函數返回地址是0xc0088eb8。這一點可以從出錯時lr的值正好等於0xc0088eb8得到印證）。調用該函數的指令是vfs_write的第49條（0xc4/4=49）指令。
達到出錯處的函數調用流程是：write(用戶空間的系統調用)–>sys_write–>vfs_write–>faulty_write
OOP消息不僅讓我定位了出錯的地方，更讓我驚喜的是，它讓我知道了一些秘密：1、gcc中fp到底有何用處？2、為什麼gcc編譯任何函數的時候，總是要把3條看上去傻傻的指令放在整個函數的最開始？3、內核和gdb是如何知道函數調用棧順序，並使用函數的名字而不是地址？ 4、我如何才能知道各個函數入棧的內容？哈哈，我漸漸喜歡上了讓內核驚訝，那就再看一次內核驚訝吧。
執行 cat /dev/faulty，內核又再一次驚訝！
1 Unable to handle kernel NULL pointer dereference at virtual address 0000000b
2 pgd = c3a88000
3 [0000000b] *pgd=33a79031, *pte=00000000, *ppte=00000000
4 Internal error: Oops: 13 [#2] PREEMPT
5 Moles linked in: faulty
6 CPU: 0 Not tainted (2.6.22.6 #4)
7 PC is at vfs_read+0xe0/0×140
8 LR is at 0xffffffff
9 pc : [] lr : [] psr: 20000013
10 sp : c38d9f54 ip : 0000001c fp : ffffffff
11 r10: 00000001 r9 : c38d8000 r8 : 00000000
12 r7 : 00000004 r6 : ffffffff r5 : ffffffff r4 : ffffffff
13 r3 : ffffffff r2 : 00000000 r1 : c38d9f38 r0 : 00000004
14 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
15 Control: c000717f Table: 33a88000 DAC: 00000015
16 Process cat (pid: 767, stack limit = 0xc38d8258)
17 Stack: (0xc38d9f54 to 0xc38da000)
18 9f40: 00002000 c3c105a0 c3c10580
19 9f60: c38d9f78 00000000 c38d9fa4 c38d9f78 c0088f88 c0088bb4 00000000 00000000
20 9f80: 00000000 00002000 bef07c80 00000003 00000003 c002c0e4 00000000 c38d9fa8
21 9fa0: c002bf40 c0088f4c 00002000 bef07c80 00000003 bef07c80 00002000 00000000
22 9fc0: 00002000 bef07c80 00000003 00000000 00000000 00000001 00000001 00000003
23 9fe0: 00000000 bef07c6c 0000266c 401adab0 60000010 00000003 00000000 00000000
24 Backtrace: invalid frame pointer 0xffffffff
25 Code: ebffff86 e3500000 e1a07000 da000015 (e594500c)
26 Segmentation fault
不過這次驚訝卻令人大為不解。OOP竟然說出錯的地方在vfs_read（要知道它可是大拿們千錘百煉的內核代碼），這怎麼可能？哈哈，萬能的內核也不能追蹤函數調用棧了，這是為什麼？其實問題出在faulty_read的43行，它導致入棧的r4、r5、r6、fp全部變為了0xffffffff，ip、lr的值未變，這樣一來faulty_read函數能夠成功返回到它的調用者——vfs_read。但是可憐的vfs_read（忠實的APTCS規則遵守者）並不知道它的r4、r5、r6已經被萬惡的faulty_read改變，這樣下去vfs_read命運就可想而知了——必死無疑！雖然內核很有能力，但缺少了正確的fp的幫助，它也無法追蹤函數調用棧。
36 ssize_t faulty_read(struct file *filp, char __user *buf,
37 size_t count, loff_t *pos)
38 {
39 int ret;
40 char stack_buf[4];
41
42
43 memset(stack_buf, 0xff, 20);
44 if (count > 4)
45 count = 4;
46 ret = _to_user(buf, stack_buf, count);
47 if (!ret)
48 return count;
49 return ret;
50 }
00000000 :
0: e1a0c00d mov ip, sp
4: e92dd870 stmdb sp!, {r4, r5, r6, fp, ip, lr, pc}
8: e24cb004 sub fp, ip, #4 ; 0×4
c: e24dd004 sub sp, sp, #4 ; 0×4，這里為stack_buf[]在棧上分配1個字的空間，局部變數ret使用寄存器存儲，因此就不在棧上分配空間了
10: e24b501c sub r5, fp, #28 ; 0x1c
14: e1a04001 mov r4, r1
18: e1a06002 mov r6, r2
1c: e3a010ff mov r1, #255 ; 0xff
20: e3a02014 mov r2, #20 ; 0×14
24: e1a00005 mov r0, r5
28: ebfffffe bl 28 //這里在調用memset
78: e89da878 ldmia sp, {r3, r4, r5, r6, fp, sp, pc}
這次OOP，深刻地認識到：
內核能力超強，但它不是，也不可能是萬能的。所以即使你能力再強，也要和你的team member搞好關系，否則在關鍵時候你會倒霉的；
出錯的是faulty_read，vfs_read卻做了替罪羊。所以人不要被表面現象所迷惑，要深入看本質；
內核本來超級健壯，可是你寫的驅動是內核的組成部分，由於它出錯，結果整體崩盤。所以當你加入一個團隊的時候一定要告誡自己，雖然你的角色也許並不重要，但你的疏忽大意將足以令整個非常牛X的團隊崩盤。反過來說，當你是team leader的時候，在選團隊成員的時候一定要慎重、慎重、再慎重，即使他只是一個小角色。
千萬別惹堆棧，它一旦出問題，定位錯誤將會是一件非常困難的事情。所以，千萬別惹你的領導，否則將死得很難看。

⑹ linux gdb backtrace 怎麼實現的

一般察看函數運行時堆棧的方法是使用GDB（bt命令）之類的外部調試器,但是,有些時候為了分析程序的BUG,(主要針對長時間運行程序的分析),在程序出錯時列印出函數的調用堆棧是非常有用的。

在glibc頭文件"execinfo.h"中聲明了三個函數用於獲取當前線程的函數調用堆棧。

[cpp] view plain print?
int backtrace(void **buffer,int size)
該函數用於獲取當前線程的調用堆棧,獲取的信息將會被存放在buffer中,它是一個指針列表。參數 size 用來指定buffer中可以保存多少個void* 元素。函數返回值是實際獲取的指針個數,最大不超過size大小
在buffer中的指針實際是從堆棧中獲取的返回地址,每一個堆棧框架有一個返回地址
注意:某些編譯器的優化選項對獲取正確的調用堆棧有干擾,另外內聯函數沒有堆棧框架;刪除框架指針也會導致無法正確解析堆棧內容

[cpp] view plain print?
char ** backtrace_symbols (void *const *buffer, int size)
backtrace_symbols將從backtrace函數獲取的信息轉化為一個字元串數組. 參數buffer應該是從backtrace函數獲取的指針數組,size是該數組中的元素個數(backtrace的返回值)

函數返回值是一個指向字元串數組的指針,它的大小同buffer相同.每個字元串包含了一個相對於buffer中對應元素的可列印信息.它包括函數名，函數的偏移地址,和實際的返回地址
現在,只有使用ELF二進制格式的程序才能獲取函數名稱和偏移地址.在其他系統,只有16進制的返回地址能被獲取.另外,你可能需要傳遞相應的符號給鏈接器,以能支持函數名功能(比如,在使用GNU ld鏈接器的系統中,你需要傳遞(-rdynamic)， -rdynamic可用來通知鏈接器將所有符號添加到動態符號表中，如果你的鏈接器支持-rdynamic的話，建議將其加上！)

該函數的返回值是通過malloc函數申請的空間,因此調用者必須使用free函數來釋放指針.

注意:如果不能為字元串獲取足夠的空間函數的返回值將會為NULL

[cpp] view plain print?
void backtrace_symbols_fd (void *const *buffer, int size, int fd)
backtrace_symbols_fd與backtrace_symbols 函數具有相同的功能,不同的是它不會給調用者返回字元串數組,而是將結果寫入文件描述符為fd的文件中,每個函數對應一行.它不需要調用malloc函數,因此適用於有可能調用該函數會失敗的情況

下面是glibc中的實例（稍有修改）：
[cpp] view plain print?
#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>

/* Obtain a backtrace and print it to @code{stdout}. */
void print_trace (void)
{
void *array[10];
size_t size;
char **strings;
size_t i;

size = backtrace (array, 10);
strings = backtrace_symbols (array, size);
if (NULL == strings)
{
perror("backtrace_synbols");
Exit(EXIT_FAILURE);
}

printf ("Obtained %zd stack frames.\n", size);

for (i = 0; i < size; i++)
printf ("%s\n", strings[i]);

free (strings);
strings = NULL;
}

/* A mmy function to make the backtrace more interesting. */
void mmy_function (void)
{
print_trace ();
}

int main (int argc, char *argv[])
{
mmy_function ();
return 0;
}
輸出如下：
[cpp] view plain print?
Obtained 4 stack frames.
./execinfo() [0x80484dd]
./execinfo() [0x8048549]
./execinfo() [0x8048556]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x70a113]

我們還可以利用這backtrace來定位段錯誤位置。
通常情況系，程序發生段錯誤時系統會發送SIGSEGV信號給程序，預設處理是退出函數。我們可以使用 signal(SIGSEGV, &your_function);函數來接管SIGSEGV信號的處理，程序在發生段錯誤後，自動調用我們准備好的函數，從而在那個函數里來獲取當前函數調用棧。
舉例如下：
[cpp] view plain print?
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <execinfo.h>
#include <signal.h>

void mp(int signo)
{
void *buffer[30] = {0};
size_t size;
char **strings = NULL;
size_t i = 0;

size = backtrace(buffer, 30);
fprintf(stdout, "Obtained %zd stack frames.nm\n", size);
strings = backtrace_symbols(buffer, size);
if (strings == NULL)
{
perror("backtrace_symbols.");
exit(EXIT_FAILURE);
}

for (i = 0; i < size; i++)
{
fprintf(stdout, "%s\n", strings[i]);
}
free(strings);
strings = NULL;
exit(0);
}

void func_c()
{
*((volatile char *)0x0) = 0x9999;
}

void func_b()
{
func_c();
}

void func_a()
{
func_b();
}

int main(int argc, const char *argv[])
{
if (signal(SIGSEGV, mp) == SIG_ERR)
perror("can't catch SIGSEGV");
func_a();
return 0;
}

編譯程序：
gcc -g -rdynamic test.c -o test; ./test
輸出如下：
[cpp] view plain print?
Obtained6stackframes.nm
./backstrace_debug(mp+0x45)[0x80487c9]
[0x468400]
./backstrace_debug(func_b+0x8)[0x804888c]
./backstrace_debug(func_a+0x8)[0x8048896]
./backstrace_debug(main+0x33)[0x80488cb]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x129113]
（這里有個疑問： 多次運行的結果是/lib/i368-Linux-gnu/libc.so.6和[0x468400]的返回地址是變化的，但不變的是後三位， 不知道為什麼）
接著：
objmp -d test > test.s
在test.s中搜索804888c如下：

[cpp] view plain print?
8048884 <func_b>:
8048884: 55 push %ebp
8048885: 89 e5 mov %esp, %ebp
8048887: e8 eb ff ff ff call 8048877 <func_c>
804888c: 5d pop %ebp
804888d: c3 ret
其中80488c時調用（call 8048877）C函數後的地址，雖然並沒有直接定位到C函數，通過匯編代碼， 基本可以推出是C函數出問題了（pop指令不會導致段錯誤的）。
我們也可以通過addr2line來查看
[cpp] view plain print?
addr2line 0x804888c -e backstrace_debug -f
輸出：
[cpp] view plain print?
func_b
/home/astrol/c/backstrace_debug.c:57

以下是簡單的backtrace原理實現：

⑺ 我的LINUX伺服器沒有strace命令，CENTOS 5.6，怎麼安裝它呢

可以使用yum -y install strace來安裝，centos系統安裝使用使用yum命令。
yum命令說明：
yum命令是在Fedora和RedHat、centos以及SUSE中基於rpm的軟體包管理器，它可以使系統管理人員交互和自動化地更細與管理RPM軟體包，能夠從指定的伺服器自動下載RPM包並且安裝，可以自動處理依賴性關系，並且一次安裝所有依賴的軟體包，無須繁瑣地一次次下載、安裝。
yum提供了查找、安裝、刪除某一個、一組甚至全部軟體包的命令，而且命令簡潔而又好記。
語法
yum(選項)(參數)
選項
-h：顯示幫助信息；
-y：對所有的提問都回答「yes」；
-c：指定配置文件；
-q：安靜模式；
-v：詳細模式；
-d：設置調試等級（0-10）；
-e：設置錯誤等級（0-10）；
-R：設置yum處理一個命令的最大等待時間；
-C：完全從緩存中運行，而不去下載或者更新任何頭文件。
參數
install：安裝rpm軟體包；
update：更新rpm軟體包；
check-update：檢查是否有可用的更新rpm軟體包；
remove：刪除指定的rpm軟體包；
list：顯示軟體包的信息；
search：檢查軟體包的信息；
info：顯示指定的rpm軟體包的描述信息和概要信息；
clean：清理yum過期的緩存；
shell：進入yum的shell提示符；
resolvedep：顯示rpm軟體包的依賴關系；
localinstall：安裝本地的rpm軟體包；
localupdate：顯示本地rpm軟體包進行更新；
deplist：顯示rpm軟體包的所有依賴關系。

⑻ linux下c操作sqlite3 運行後(編譯沒有錯）當我輸入4（insert-data）直接說段錯誤TAT

段錯誤 用strace來追蹤。