`gdb`无法展开堆栈 [英] `gdb` unable to unwind a stack
问题描述
考虑以下（破碎）代码：
#include >
#include< memory>
使用namespace std;
class Test {
public：
unique_ptr< string> S;
Test（）：s（NULL）{
}
void update（string& st）{
s = unique_ptr< string>（& （ST））;
}
};
void update（Test& t）{
string s（Hello to you）;
t.update（s）;
}
int main（）{
Test t;
update（t）;
cout<< * t.s<< ENDL;
这里我们在方法 Test :: update （）我们不做一个对象的uniq副本。所以当程序在macOS下运行时，你会得到：
$ ./test
Hellot E]
test（44981,0x7fff99ba93c0）malloc：***对象错误0x7fff5d45b690：释放的指针未分配
***在malloc_error_break中设置断点以调试
[1] 44981 abort ./test
我已经能够使用<$ c $成功调试这个案例C> LLDB 。即使没有在 malloc_error_break 中设置断点，只是运行应用程序，直到它被捕获到 SIGABRT 处理程序中。
lldb ./test
（lldb）target创建./test
将当前可执行文件设置为' ./test'（x86_64）。
（lldb）运行
启动过程44993：'./test'（x86_64）
您好t _
测试（44993,0x7fff99ba93c0）malloc：对象0x7fff5fbff680的***错误：被释放的指针没有被分配
***在malloc_error_break中设置一个断点来调试
进程44993停止
*线程＃1，queue ='com.apple .main-thread'，stop reason = signal SIGABRT
frame＃0：0x00007fff90d6cd42 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill：
- > 0x7fff90d6cd42< + 10> ;: jae 0x7fff90d6cd4c; 1 + 20 - ;
0x7fff90d6cd44< + 12> ;: movq％rax，％rdi
0x7fff90d6cd47< + 15> ;: jmp 0x7fff90d65caf; cerror_nocancel
0x7fff90d6cd4c< + 20>：retq
目标0：（测试）停止。
（lldb）bt
*线程＃1，queue ='com.apple.main-thread'，stop reason = signal SIGABRT
* frame＃0：0x00007fff90d6cd42 libsystem_kernel。 dylib`__pthread_kill + 10
frame＃1：0x00007fff90e5a457 libsystem_pthread.dylib`pthread_kill + 90
frame＃2：0x00007fff90cd2420 libsystem_c.dylib`abort + 129 $ b $ frame＃3：0x00007fff90dc1fe7 libsystem_malloc.dylib` free + 530
frame＃4：0x0000000100001f7b test`Test ::〜Test（）[inlined] std :: __ 1 :: default_delete< std :: __ 1 :: basic_string< char，std :: __ 1 :: char_traits< char>，std :: __ 1 :: allocator< char> > > :: operator（this = 0x00007fff5fbff730，__ptr =\a\x94\x99 \x7f\\\\\\\\\\\\\\'（this = 0x00007fff5fbff730，__ptr =\a\x94\x99 \x7f\\\\\\\\' \x7f\0\00_\x7f\0\00_\x7f\0\00_\x7f\0\00_\\ \\x7f\0\00_\x7f\0\0_\x7f\0\0\x15\x1e\0\0\x01\ 0（std :: __ 1 :: basic_string< char，std :: __ 1 :: char_traits< char> ;, std :: __ 1 :: allocator< char>> *）const在内存中：2397
frame＃5：0x0000000100001f46 test`Test ::〜Test（）[inlined] std :: __ 1 :: unique_ptr
frame＃9： 0x0000000100001e15 test`Test ::〜test（this = 0x00007fff5fbff730）at main.cpp：6
frame＃10：0x0000000100001ab6 test`main at main.cpp：28
frame＃11：0x00007fff90c3e235 libdyld.dylib`开始+ 1
现在我发现问题出现在 不幸的是，试图使用 问题是：为什么 为什么gdb无法正确地展开堆栈 Mac OS X Sierra使用gdb时存在一些问题，请参阅这篇文章和 gdb bug报告。 如果我需要使用gdb获取正确的backtrace，我有什么选择？ 您可以尝试降级Mac OS（不知道是否可以）或尝试应用临时破解补丁。 Consider following (broken) code: Here we have error in method I've been able to to debug this case successfully using Now I see that the problem is in Unfortunately, trying to debug this case using The question is: why why gdb fails to unwind the stack correctly There are some problems on Mac OS X Sierra with gdb, see this post and gdb bug report. what options do I have if I need to get correct backtrace using gdb You can try to downgrade Mac OS (don't know whether is it possible) or try to apply temporary hack patch from above bug report. 这篇关于`gdb`无法展开堆栈的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！ Test
gdb
$ $ $ $ gdb ./test
GNU gdb（GDB）8.0.1
版权所有（C）2017自由软件基金会，Inc.
许可证GPLv3 +：GNU GPL版本3或更高版本< http：//gnu.org/licenses/gpl.html>
这是免费软件：您可以自由更改和重新分配它。
在法律允许的范围内，不存在任何担保。有关详细信息，请键入显示复制
和显示保修。
这个GDB被配置为x86_64-apple-darwin16.7.0。
输入显示配置以获取配置详细信息。
有关错误报告的说明，请参阅：
< http：//www.gnu.org/software/gdb/bugs/> ;.
在线查找GDB手册和其他文档资源：
< http：//www.gnu.org/software/gdb/documentation/> ;.
如需帮助，请输入help。
键入apropos word以搜索与word相关的命令...
阅读测试中的符号...阅读/ Users / bazhenov / Developer / linear-counter / tests / test / test.dSYM /内容/资源/ DWARF /测试...完成。
完成。
（gdb）run
启动程序：/ Users / bazhenov / Developer / linear-counter / tests / test / test
[进程45204的新线程0x1403]
警告：未处理的dyld版本（15）
你好tQ _
测试（45204,0x7fff99ba93c0）malloc：***对象错误0x7fff5fbff650：被释放的指针未被分配
** *在malloc_error_break中设置一个断点来调试
线程2收到信号SIGABRT，中止。
0x00007fff90d6cd42在?? （）
（gdb）bt
＃0 0x00007fff90d6cd42 in ?? （）
＃1 0x00007fff90e5a457 in ?? （）
＃2 0x00007fff5fbff590 in ?? （）
＃3 0x0000030700000000 in ?? （）
＃4 0x00007fff5fbff590 in ?? （）
＃5 0x00007fff5fbff650在？ （）
＃6 0x00007fff5fbff5a0在？ （）
＃7 0x00007fff90cd2420 in ?? （）
＃8 0xffffffff00000018在?? （）
＃9 0x00007fff5fbff5b0在？ （）
＃10 0x00007fffffffffdf在？ （）
＃11 0x00000001000c4000 in ?? （）
＃12 0x00007fff5fbff5f0在？ （）
＃13 0x00007fff90dc1fe7在？ （）
＃14 0x378b45e65b700074在?? （）
＃15 0x00007fff99ba00ac在?? （）
＃16 0x0000000000000000 in ?? （）
（gdb）
gdb 无法正确展开堆栈，如果我需要使用 gdb ？
来获得正确的回溯，
#include <iostream>
#include <memory>
using namespace std;
class Test {
public:
unique_ptr<string> s;
Test() : s(NULL) {
}
void update(string& st) {
s = unique_ptr<string>(&(st));
}
};
void update(Test& t) {
string s("Hello to you");
t.update(s);
}
int main() {
Test t;
update(t);
cout << *t.s << endl;
}
Test::update() we do not make a uniq copy of an object. So when the program is run under macOS, you'll get:$ ./test
Hello t��E]�
test(44981,0x7fff99ba93c0) malloc: *** error for object 0x7fff5d45b690: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[1] 44981 abort ./test
lldb. Even without setting a breakpoint in malloc_error_break, just running application until it gets caught in SIGABRT handler.lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 44993 launched: './test' (x86_64)
Hello t��_�
test(44993,0x7fff99ba93c0) malloc: *** error for object 0x7fff5fbff680: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Process 44993 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff90d6cd42 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff90d6cd42 <+10>: jae 0x7fff90d6cd4c ; <+20>
0x7fff90d6cd44 <+12>: movq %rax, %rdi
0x7fff90d6cd47 <+15>: jmp 0x7fff90d65caf ; cerror_nocancel
0x7fff90d6cd4c <+20>: retq
Target 0: (test) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff90d6cd42 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff90e5a457 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x00007fff90cd2420 libsystem_c.dylib`abort + 129
frame #3: 0x00007fff90dc1fe7 libsystem_malloc.dylib`free + 530
frame #4: 0x0000000100001f7b test`Test::~Test() [inlined] std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::operator(this=0x00007fff5fbff730, __ptr="\a\x94\x99�\x7f\0\0��_�\x7f\0\0\x80�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\00�_�\x7f\0\0��_�\x7f\0\0\x15\x1e\0\0\x01\0\0\0\x80�_�\x7f\0\n0")(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) const at memory:2397
frame #5: 0x0000000100001f46 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::reset(this=0x00007fff5fbff730, __p="") at memory:2603
frame #6: 0x0000000100001ef3 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::~unique_ptr(this=0x00007fff5fbff730) at memory:2571
frame #7: 0x0000000100001ef3 test`Test::~Test() [inlined] std::__1::unique_ptr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::default_delete<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::~unique_ptr(this=0x00007fff5fbff730) at memory:2571
frame #8: 0x0000000100001ef3 test`Test::~Test(this=0x00007fff5fbff730) at main.cpp:6
frame #9: 0x0000000100001e15 test`Test::~Test(this=0x00007fff5fbff730) at main.cpp:6
frame #10: 0x0000000100001ab6 test`main at main.cpp:28
frame #11: 0x00007fff90c3e235 libdyld.dylib`start + 1
Test destructor, and from here it's a piece of cake.gdb under macOS was a total failure. Here is what I've done:$ gdb ./test
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 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-apple-darwin16.7.0".
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 test...Reading symbols from /Users/bazhenov/Developer/linear-counter/tests/test/test.dSYM/Contents/Resources/DWARF/test...done.
done.
(gdb) run
Starting program: /Users/bazhenov/Developer/linear-counter/tests/test/test
[New Thread 0x1403 of process 45204]
warning: unhandled dyld version (15)
Hello tQ�_�
test(45204,0x7fff99ba93c0) malloc: *** error for object 0x7fff5fbff650: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Thread 2 received signal SIGABRT, Aborted.
0x00007fff90d6cd42 in ?? ()
(gdb) bt
#0 0x00007fff90d6cd42 in ?? ()
#1 0x00007fff90e5a457 in ?? ()
#2 0x00007fff5fbff590 in ?? ()
#3 0x0000030700000000 in ?? ()
#4 0x00007fff5fbff590 in ?? ()
#5 0x00007fff5fbff650 in ?? ()
#6 0x00007fff5fbff5a0 in ?? ()
#7 0x00007fff90cd2420 in ?? ()
#8 0xffffffff00000018 in ?? ()
#9 0x00007fff5fbff5b0 in ?? ()
#10 0x00007fffffffffdf in ?? ()
#11 0x00000001000c4000 in ?? ()
#12 0x00007fff5fbff5f0 in ?? ()
#13 0x00007fff90dc1fe7 in ?? ()
#14 0x378b45e65b700074 in ?? ()
#15 0x00007fff99ba00ac in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb)
gdb fails to unwind the stack correctly and what options do I have if I need to get correct backtrace using gdb?
