2016-08-18 157 views
0

我知道有一个类似​​在那里。但我认为这个问题是不同的。GDB的腐败堆栈问题,不显示功能和行号

我使用gdb-cross-aarch64来分析arm arch64设备上生成的转储核心文件。

我的命令行是这样的:

gdb-cross-aarch64 /path_to/gst-launch-1.0 /path_to/core.2135 

gst-launch-1.0是取决于LIB libOmxCore.so共享。

这里是gdb的输出:

GNU gdb (GDB) 7.9.1 
Copyright (C) 2015 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=x86_64-linux --target=aarch64-poky-linux". 
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 ./work/aarch64-poky-linux/gstreamer1.0/1.4.5-r0/image/usr/bin/gst-launch-1.0...done. 
[New LWP 2135] 
[New LWP 2137] 
[New LWP 2141] 
[New LWP 2139] 
[New LWP 2138] 
[New LWP 2136] 
[New LWP 2143] 
[New LWP 2142] 
[New LWP 2140] 

warning: Could not load shared library symbols for 46 libraries, e.g. linux-vdso.so.1. 
Use the "info sharedlibrary" command to see the complete listing. 
Do you need "set solib-search-path" or "set sysroot"? 
Core was generated by `gst-launch-1.0 filesrc location=samplevideo.mp4 ! decodebin ! fakesink'. 
Program terminated with signal SIGABRT, Aborted. 
#0 0x0000007fa1d42cb0 in ??() 
(gdb) set sysroot /Disk_1/Alan_s_Work/path_to/image/ 
Reading symbols from /Disk_1/Alan_s_Work/path_to/libOmxCore.so...done. 
(gdb) bt 
#0 0x0000007fa1d42cb0 in ??() 
#1 0x0000007fa1d46120 in ??() 
Backtrace stopped: previous frame identical to this frame (corrupt stack?) 
(gdb) 

如上所示,我已经设置在gdb的sysroot,和在libOmxCore.sogst-launch-1.0符号由gdb读取。

但我仍然无法通过gdb看到有效的堆栈回溯。

我很确定signal SIGABRTlibOmxCore.so引起的。

我在这里做错了什么?或者我还应该做什么?

谢谢你

回答

0

这些都是棘手的错误找到。调试器通过向上走过您提供的核心转储的堆栈帧来获取它通常显示的回溯信息。

在堆栈损坏的情况下,显然没有任何有用的信息可以用于创建回溯或反向论证:如果看不到适当的回溯,代码会破坏堆栈。调试器可以为您提供的验尸并不多。

损坏的堆栈,特别是使用外部库时,可能会出现大量原因。有些是:

  1. 移交记忆库希望看到在堆栈上
  2. 移交指向一个堆栈变量不再有效(如指针返回到局部变量)
  3. 告诉图书馆有关您给它的变量或缓冲区大小的错误故事。
  4. 移交标量而不是指针
  5. 假设库将分配缓冲区并返回指针,但库存在其他情况。
  6. ...和一个巨大的其他可能的原因量...

手动完成对你的代码,对准你需要的库的需求来分配存储区。找出库的工作内存(是你的代码还是分配它的库),并仔细检查它是否足够满足需求。

SIGABRT被送到一个巨大的原因量,有些你可能想在一个位显得更加强烈:

  1. 线程运行野生(即不是join编为
  2. 任何事情堆管理像mallocfree不当指针
  3. 和任何在您的图书馆发现自己在一个情况下与程序事情是不可能的。
+0

谢谢@tofro。 “我非常确定信号SIGABRT是由libOmxCore.so引起的” 因为我故意在libOmxCore.so函数中设置了“assert(0)”。因为我想指导自己如何使用'gdb'。 – Alan