bug是如何被修正的

2021-05-22 20:59:32 字數 1043 閱讀 9426

copy了rumination on c++中的一段控制代碼類生成樹形表示式的程式,第一次匆匆的修正執行後隔了一段時間在第二次重新修正時仍然困難重重,這才了解以前沒有真確的掌握除錯的一些技巧,做個學習總結。

源**部分如下:

driver.cpp 驅動函式

expr.h 標頭檔案,包含有兩個類?:控制代碼類expr,為了獲得公共介面而設計的類expr_node

class expr_node{

friend ostream& operator<<(ostream&, const expr&);

friend class expr;

class expr

{ friend ostream& operator<<(ostream&, const expr&);

expr_node* p;

vc中編譯時遇到的看似比較棘手的乙個問題是:

error c2679: binary '<<'

g++ -c driver.cpp

iso c++ forbids declaration of 'ostream' with no  type

這樣的提示比error c2679要明顯的多(雖然都是指向同乙個錯誤原因)。這樣很容易修正bug

在expr.h的宣告中新增:

using std::ostream;

到這裡只是本演示修正的第一步:)

再次執行g++ -c driver.cpp,得到編譯後的鏈結檔案driver.o

此時進行鏈結, g++ -o driver driver.o

得到預設可執行檔案driver

但是執行driver,gcc提示

segment error.

怎麼知道是什麼樣的段錯誤引發了呢?

這是就用到了gdb

gdb ./driver

gdb run

至此錯誤資訊已經被定位出來了,是

~expr::expr()

系統給programmer的提示是段錯誤是由於析構函式的錯誤書寫引發的,這樣就很容易進行修改了。

修正至此算是告一段落了。

專案bug的修正

這幾個月來,大部分業餘時間,都花在閱讀軟體工程和編譯原理方面的書籍上了。軟體工程方面的書,包括軟體需求 風險管理 敏捷建模,系統設計,軟體專案管理,還有一些類似於的沉思錄書籍等。在這些書中,都只是講了如何讓專案健康發展,最後成功的提交乙個產品。儘管它們都是從不同的角度,用不同的方法去完成同樣的事。但...

Tomcat修正JDK原生執行緒池bug的實現原理

為提高處理能力和併發度,web容器一般會把處理請求的任務放到執行緒池,而jdk的原生執行緒池先天適合cpu密集型任務,於是tomcat改造之。其實threadpoolexecutor的引數主要有如下關鍵點 限制執行緒個數 限制佇列長度 而tomcat對這倆資源都需要限制,否則高併發下cpu 記憶體都...

揭秘 HackingTeam的資料是如何被偷的?

攻擊者通過獲得受害者正在登入的員工電腦的訪問許可權,從而竊取了hacking team的資料。攻擊者可能是直接獲取了安全工程師christian pozzi的電腦的物理訪問許可權,也可能是通過惡意軟體實現了類似的訪問級別。無論哪種方式,我們可以確定,christian當時正處於登入狀態,這可以通過網...