2010-07-23 85 views
2

我正在構建以前的工作代碼,但我得到一個seg故障,我無法弄清楚出了什麼問題。 gdb捕獲錯誤,但它並沒有指出一個明顯的原因。它顯示的源代碼行是一個函數名,所以它甚至沒有進入函數。如果我看看指令的解構,它仍然在設置堆棧,所以堆棧可能會混亂。那麼我應該如何去調試呢?這是在QNX 6.2中,僅用於控制檯gdb。我怎樣才能在gdb中調試這個SIGSEV?

0x0816b829 in __ml (this=0x79b963c, anMultiplier=0) at ../u_matrix.cpp:56 
56  tcMatrix tcMatrix::operator*(float64 anMultiplier) 

0x816b820 <__ml>:  push %ebp 
0x816b821 <__ml+1>:  mov %esp,%ebp 
0x816b823 <__ml+3>:  sub $0x13ac,%esp 
0x816b829 <__ml+9>:  push %edi 
0x816b82a <__ml+10>: push %esi 
0x816b82b <__ml+11>: push %ebx 

回答

4

你正在崩潰的指令是push %edi

這很可能意味着你有堆棧溢出。

堆棧溢出的一個可能原因是無限遞歸。如果(gdb) where顯示不斷的函數調用流,那就是你的問題。

如果where顯示合理的通話順序,重複執行info frameup,查找具有不合理大尺寸的幀。

最後,問題可能是由於您的執行環境發生了變化,而不是由程序中的任何內容引起的。我不確定什麼QNX相當於ulimit -s,但可能您的堆棧限制太小。

1

如果在gdb中執行「bt」,有什麼相關的?

-1

你也可以嘗試valgrind'ing它,它可以給更多的信息。

+0

因爲確實在Valgrind的支持QNX? – 2010-07-24 03:33:33

+0

哎呦,我的錯誤,對此感到抱歉 – Zev 2010-08-12 19:12:50

1

「this」指針看起來很亂 - 0x79b963c似乎關閉,但可能取決於對象如何初始化。嘗試

print * this

並查看數據是否有意義或是垃圾。它也看起來像你的源不匹配的可執行文件 - 你在示例中的行看起來像一個運算符覆蓋聲明,而不是可執行文件。

我會忽略特定的行,在源代碼中查找整個_ml函數,並嘗試打印一些局部變量以查看您是否在循環或其他範圍內。

我猜你有一個矩陣乘法運算符,其中矩陣乘以一個浮點數 - 很可能這是類似於索引超出範圍,某種類型的內存問題,你在內存範圍外運行並損壞了堆棧。

像Unknown說的,嘗試bt以及 - 如果它回來了很多??()的,那麼你確實有一個腐敗的堆棧。

2

繼俄羅斯就業的回答:

的ulimit -s QNX的作品,但它是默認無限。

我將實驗

ldrel -S2M -L yourexecutablename

調節初始的堆棧分配/懶惰,看是否核心轉儲再次發生。您還可以使用QCC的-N標誌將初始堆棧大小設置得更高。