Question

我知道那里有类似的 question。但我认为这个问题不同。

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

我的命令行如下：

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

和gst-launch-1.0取决于共享库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.so和gst-launch-1.0中的符号由gdb读取。

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

我很确定signal SIGABRT是由libOmxCore.so造成的。

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

谢谢

Answer 1

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

如果堆栈已损坏，显然没有任何可用于创建回溯的有用信息，或反向论证：如果您看不到正确的回溯，则代码会损坏堆栈。调试器可以给你的验尸帮助不多。

损坏的堆栈，尤其是在使用外部库时，可能会因为大量原因而发生。有些是：

移交内存，库希望在堆栈上的堆上看到
将指针移交给不再有效的堆栈变量（比如返回指向局部变量的指针）
告诉图书馆有关你给它的变量或缓冲区大小的错误故事。
移交标量而不是指针
假设库将分配缓冲区和回拨指针，但是库假设不然。
......以及其他可能的原因......

手动浏览代码，将需要分配的内存区域与库的要求对齐。找出库所使用的内存的所有权（是您的代码还是分配它的库），并仔细检查它是否足以满足要求。

SIGABRT的发送有很多原因，有些你可能想要更强烈地看一下：

一个疯狂的线程（即不是join为
关于堆管理的任何内容，例如malloc和free指针不正确
任何你的图书馆发现自己无法继续使用该程序的情况。

gdb损坏的堆栈问题，而不是显示的功能和行号

1 个答案: