2015-08-15 35 views
1

「回溯已停止:與此幀相同的前一幀(損壞的堆棧?我複製了核心轉儲文件,並嘗試在x86_64主機上使用arm-gdb獲取回溯。這是O/P:「在Linux上運行應用程序(ARM體系結構)時,我試圖調試一個段錯誤(segfault)」,在linux linux

$ arm-arago-linux-gnueabi-gdb test_slave6_slave core 
GNU gdb (GDB) 7.4 
Copyright (C) 2012 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "--host=i686-oesdk-linux --target=arm-oe-linux-gnueabi". 
For bug reporting instructions, please see: 
<http://www.gnu.org/software/gdb/bugs/>... 
Reading symbols from /home/dvdk/test_slave6_slave...done. 

warning: exec file is newer than core file. 
[New LWP 6411] 
[New LWP 6410] 

warning: Could not load shared library symbols for 12 libraries, e.g. /lib/libjson-c.so.2. 
Use the "info sharedlibrary" command to see the complete listing. 
Do you need "set solib-search-path" or "set sysroot"? 
Core was generated by `/usr/bin/test_slave6_slave 5 111.111.111.111 1 2 1 2'. 
Program terminated with signal 11, Segmentation fault. 
#0 0x47b61dd4 in ??() 
(gdb) bt 
#0 0x47b61dd4 in ??() 
#1 0x47b2e0fc in ??() 
#2 0x47b2e0fc in ??() 
Backtrace stopped: previous frame identical to this frame (corrupt stack?) 
(gdb) 

(時間戳警告,可能是因爲我第一次複製的核心文件)

我不認爲this問題,因爲我得到有效的地址,我的問題是相同的。我認爲這仍然是一個堆棧腐敗問題。但我不知道如何進一步調試。我應該使用GDB還是valgrind?有人能指出我使用這些工具進行調試的正確步驟嗎?例如,我應該使用帶leak_check的valgrind使用memecheck嗎?

更新1:我正在使用libcurl進行https請求。我注意到當另一個沒有ssl支持的libcurl版本被使用時,崩潰不會發生。 (查詢將失敗)。啓用了ssl的libcurl是我自定義編譯的。

+0

Gdb給你一個建議,看一下'info sharedlibrary',這個命令的輸出是什麼?但是,我更關心'exec文件比核心文件更新'這樣的警告,你是否正在構建正確的共享庫? –

回答

0

爲後人的緣故:

這裏的問題是最有可能只是調試器無法檢查該程序使用運行相同的共享庫,就像它在它打印的信息說。

較早版本的GDB(例如問題中使用的7.4)需要將庫安排在與目標系統上完全相同的樹結構中。因此,您需要將二進制文件中使用的所有庫複製到具有與目標主機上完全相同的層次結構的目錄中。如果你的名字此目錄target那麼你可以告訴GDB找到它的庫與set sysroot ./target/

看來,如果GDB的更現代的版本只能找到每一個庫,如果它們都收集到一個目錄下,然後你可以告訴GDB,你把它們放在set solib-absolute-prefixset solib-search-path這兩個地方都指向這個目錄。我有時候在第一次正確工作時仍然遇到一些麻煩,我必須從頭開始多次重試,以便正確排列所有咒語並按正確順序排列。

在這裏,我使用了最新版本的GDB,其中包含~/tmp/arm-lib中的所有庫。請注意,我沒有把核心文件名放在命令行上!

$ gdb ktest-arm 
GNU gdb (GDB) 7.12.0.20161109-git 
Copyright (C) 2016 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "x86_64-pc-linux-gnu". 
Type "show configuration" for configuration details. 
For bug reporting instructions, please see: 
<http://www.gnu.org/software/gdb/bugs/>. 
Find the GDB manual and other documentation resources online at: 
<http://www.gnu.org/software/gdb/documentation/>. 
For help, type "help". 
Type "apropos word" to search for commands related to "word"... 
Reading symbols from ktest-arm...done. 
(gdb) show architecture 
The target architecture is set automatically (currently arm) 
(gdb) set solib-absolute-prefix ~/tmp/arm-lib/ 
(gdb) set solib-search-path ~/tmp/arm-lib/ 
(gdb) core-file ~/tmp/ktest-arm-core 
warning: core file may not match specified executable file. 
[New LWP 905] 
Core was generated by `./ktest'. 
Program terminated with signal SIGQUIT, Quit. 
#0 0x40134264 in nanosleep() from /home/woods/tmp/arm-lib/libc.so.6 
(gdb) bt 
#0 0x40134264 in nanosleep() from /home/woods/tmp/arm-lib/libc.so.6 
#1 0x00008c9c in main() at /home/woods/tmp/testing/ktest.c:9 
(gdb)