如果构造函数从调用 std::make_shared 崩溃，gdb 可以显示崩溃的详细信息答案

【问题标题】：if constructor crashes from call to std::make_shared, can gdb show details of crash如果构造函数从调用 std::make_shared 崩溃，gdb 可以显示崩溃的详细信息
【发布时间】：2017-03-30 14:02:30
【问题描述】：

在下面的代码中，我调用了make_shared<MyClass>，MyClass 的构造函数抛出了异常。如果 core 文件可用，是否可以借助 gdb 找出 crash 的根源[例如：crash 是来自 foo() 还是 fun()]？

#include <iostream>
#include <memory>
using namespace std;

class MyClass
{
    public:
        MyClass()
        {
            foo();
            fun();
        }

        ~MyClass() { }

        void foo()
        {
            throw("error 1");
        }
        void fun()
        {
            throw("error 2");
        }
};


shared_ptr<MyClass> createMyClass()
{
    return make_shared<MyClass>();
}

int main()
{
    shared_ptr<MyClass> c = createMyClass();
    return 0;
}

backtrace 只指向这一行：

 29     return make_shared<MyClass>();

回溯：

Program received signal SIGABRT, Aborted.
0x00007ffff722d5f7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-106.el7_2.6.x86_64 libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64

    (gdb) bt
    #0  0x00007ffff722d5f7 in raise () from /lib64/libc.so.6
    #1  0x00007ffff722ece8 in abort () from /lib64/libc.so.6
    #2  0x00007ffff7b329d5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
    #3  0x00007ffff7b30946 in ?? () from /lib64/libstdc++.so.6
    #4  0x00007ffff7b30973 in std::terminate() () from /lib64/libstdc++.so.6
    #5  0x00007ffff7b30be9 in __cxa_rethrow () from /lib64/libstdc++.so.6
    #6  0x000000000040121e in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<MyClass, std::allocator<MyClass>>(std::_Sp_make_shared_tag, MyClass*, std::allocator<MyClass> const&) (this=0x7fffffffe178, __a=...) at /usr/include/c++/4.8.2/bits/shared_ptr_base.h:509
    #7  0x00000000004010ba in std::__shared_ptr<MyClass, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<MyClass>>(std::_Sp_make_shared_tag, std::allocator<MyClass> const&) (this=0x7fffffffe170, __tag=..., __a=...) at /usr/include/c++/4.8.2/bits/shared_ptr_base.h:957
    #8  0x0000000000401052 in std::shared_ptr<MyClass>::shared_ptr<std::allocator<MyClass>>(std::_Sp_make_shared_tag, std::allocator<MyClass> const&) (this=0x7fffffffe170,
        __tag=..., __a=...) at /usr/include/c++/4.8.2/bits/shared_ptr.h:316
    #9  0x0000000000400f98 in std::allocate_shared<MyClass, std::allocator<MyClass>>(std::allocator<MyClass> const&) (__a=...) at /usr/include/c++/4.8.2/bits/shared_ptr.h:598
    #10 0x0000000000400ee0 in std::make_shared<MyClass<> > () at /usr/include/c++/4.8.2/bits/shared_ptr.h:614
    #11 0x0000000000400ce3 in createMyClass () at abrt.cpp:29
    #12 0x0000000000400cfe in main () at abrt.cpp:34
    (gdb) q

【问题讨论】：

从回溯中获取结果的最佳方法是在关闭所有优化的情况下进行编译。否则编译器可能会选择内联函数，并且回溯会丢失一些东西。在没有任何优化标志的情况下重新编译，看看你是否能从中得到更好的回溯。
请展示您如何构建此代码。
@SamVarshavchik，我用 -O0 试过了，结果还是一样。
@ks1322 ，我正在编译为“ g++ -ggdb -O0 -std=c++11 abrt.cpp”

标签： c++ c++11 gdb shared-ptr core

【解决方案1】：

在生成核心文件时，该信息已丢失。原因是shared_ptr 构造函数必须从对象构造函数中捕获任何异常，以便能够释放它之前分配的内存（以防止由throw 的构造函数引起的泄漏）。当它捕获到异常以释放内存时，它不再知道在构造函数中的哪个位置引发了异常。

【讨论】：