【问题标题】:"Backtrace stopped: previous frame identical to this frame (corrupt stack?)" on ARM linuxARM linux上的“回溯停止:前一帧与此帧相同(损坏的堆栈?)”
【发布时间】:2015-11-08 12:03:37
【问题描述】:

我正在尝试在 linux(ARM 架构)上运行应用程序时调试段错误。我复制了核心转储文件并尝试在 x86_64 主机上使用 arm-gdb 获取回溯。这是o/p:

$ 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?有人可以指出我使用这些工具进行调试的正确步骤。例如,我应该将 memecheck 与 valgrind 与 leak_check 一起使用吗?

更新 1: 我将 libcurl 用于 https 请求。我注意到当使用不支持 ssl 的另一个版本的 libcurl 时不会发生崩溃。 (查询当然会失败)。启用 ssl 的 libcurl 是我自定义编译的。

【问题讨论】:

  • gdb 给你一个建议去看看info sharedlibrary,这个命令的输出是什么?但是,我更关心警告exec file is newer than core file,您是否针对正确的共享库进行构建?

标签: linux gdb arm valgrind stack-corruption


【解决方案1】:

为了后代:

这里的问题很可能只是调试器无法检查程序运行时使用的相同共享库,正如它在打印的消息中所说的那样。

旧版本的 GDB(例如问题中使用的 7.4)需要将库排列在与目标系统上完全相同的树结构中。因此,对于它,您需要将二进制文件使用的所有库复制到具有与目标主机上完全相同的层次结构的目录中。如果您将此目录命名为target,那么您可以使用set sysroot ./target/ 告诉GDB 查找其中的库

似乎更现代的 GDB 版本只能找到每个库,如果它们都被收集到一个目录中,然后您可以使用 set solib-absolute-prefixset solib-search-path 告诉 GDB 将它们放在哪里,同时指向这个目录。有时我在第一次使其正常工作时仍然遇到一些问题,我必须从头开始重试几次,以使所有咒语都正确且顺序正确。

在这里,我使用了一个更新的 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) 

【讨论】:

  • 在调试本地进程时得到与 OP 完全相同的错误。我已经在 20 分钟前构建了那个程序。这一切都发生在同一台机器上,构建、崩溃和调试。
  • @Sonts 如果是本地进程,即构建和执行主机相同,则不太可能与此问题相同。如果您发布了详细信息,尤其是示例调试器会话的记录,您可能会在新问题上获得更好的帮助。
猜你喜欢
  • 2019-03-30
  • 1970-01-01
  • 2019-03-02
  • 2014-11-30
  • 2012-04-06
  • 2019-07-28
  • 2014-09-27
  • 2020-10-27
  • 2013-09-16
相关资源
最近更新 更多