2011-09-19 78 views
1

我在嵌入式設備上的Linux上。 我的架構是armv5。如何在armv5上調試堆損壞

我相當大(〜30kloc)有隨着時間的推移發生某種堆腐敗。

我不能運行valgrind,因爲我的拱不被支持。 我只能運行有限的gdb,因爲我的應用程序使用線程,並且最可能發生的損壞發生在一個線程中。

我得到

警告:無法找到匹配libthread_db所劣質的線程 庫,線程調試將不可用。

libthread_db和libpthread來自我的gnueabi工具鏈。

我想知道現在最好的行動是什麼。我應該不斷嘗試讓libthread_db與gdb一起工作嗎?還是有一些其他工具,如valgrind,我可以使用?

+1

可以a)將代碼移植到您的桌面操作系統並在那裏使用valgrind,或者b)替換全局'new'和軌道分配? –

+0

如何更換全球新款? – Eric

+0

http://www.informit.com/articles/article.aspx?p=30642&seqNum=3 – celavek

回答

3

警告:無法找到匹配劣質線程庫的libthread_db,線程調試將不可用。

這個錯誤意味着GDB試圖dlopenlibthread_db.so.1libthread-db-search-path(使用show libthread-db-search-path,看看那是什麼),以及libthread_db.so.1所有版本失敗,你有目標(嵌入式設備)libpthread工作。

很可能您的libthread-db-search-path根本不正確。

另一種可能性是,您的工具鏈出貨(例如)i686-linux版本libthread_db.so.1,但您使用的是爲x86_64-linux構建的GDB。 64位GDB(顯然)無法刪除32位libthread_db

即使您設法正確地設置了多線程調試(您應該嘗試在任何情況下),這很可能不會幫助您找到堆損壞問題:通常在您遇到由於堆腐敗,實際造成它的所有代碼痕跡都消失了。

如果您在目標上使用glibcMALLOC_CHECK_=2可能會有所幫助。文檔here

如果您使用其他一些libc,它可能有類似的malloc調試工具。或者您可以嘗試使用manydebugmallocs之一。

+0

我知道libthread-db -search-path配置,但它不能解決我的問題。我的工具鏈和gdb都在我的設備上運行,我已經用上述工具鏈交叉編譯了gdb – Eric

+0

另外我使用C++,所以我沒有任何malloc,只有新聞。這是否仍然有效? – Eric

+0

我用gdb打賭的是檢查某個特定變量的內存位置是否被覆蓋,然後在該位置設置一個內存監視。可能或可能不工作... – Eric