2

在我的应用程序正确完成所有操作后，我收到此错误消息

/lib64/libc.so.6[0x3f1ee70d7f]
/lib64/libc.so.6(cfree+0x4b)[0x3f1ee711db]
/home/user/workspace/NewProject/build/bin/TestApp(_ZN9__gnu_cxx13new_allocatorIN5boost10shared_ptrINS1_5uuids4uuidEEEE10deallocateEPS5_m+0x20)[0x49c174]
/home/user/workspace/NewProject/build/bin/TestApp(_ZNSt12_Vector_baseIN5boost10shared_ptrINS0_5uuids4uuidEEESaIS4_EE13_M_deallocateEPS4_m+0x32)[0x495b84]
/home/user/workspace/NewProject/build/bin/TestApp(_ZNSt12_Vector_baseIN5boost10shared_ptrINS0_5uuids4uuidEEESaIS4_EED2Ev+0x47)[0x49598b]
/home/user/workspace/NewProject/build/bin/TestApp(_ZNSt6vectorIN5boost10shared_ptrINS0_5uuids4uuidEEESaIS4_EED1Ev+0x65)[0x48bf27]
/lib64/libc.so.6(__cxa_finalize+0x8e)[0x3f1ee337fe]
/home/user/workspace/NewProject/build/components/lib_path/libhelper-d.so[0x2aaaab052b36]

如果我在其中运行程序，gdb我可以获得以下回溯，但这就是我得到的全部：

#0  0x0000003f1ee30285 in raise () from /lib64/libc.so.6
#1  0x0000003f1ee31d30 in abort () from /lib64/libc.so.6
#2  0x0000003f1ee692bb in __libc_message () from /lib64/libc.so.6
#3  0x0000003f1ee70d7f in _int_free () from /lib64/libc.so.6
#4  0x0000003f1ee711db in free () from /lib64/libc.so.6
#5  0x000000000049c174 in __gnu_cxx::new_allocator<boost::shared_ptr<boost::uuids::uuid> >::deallocate (this=0x2aaaab2cea50, __p=0x1cfd8d0)
    at /opt/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.5/../../../../include/c++/4.4.5/ext/new_allocator.h:95
#6  0x0000000000495b84 in std::_Vector_base<boost::shared_ptr<boost::uuids::uuid>, std::allocator<boost::shared_ptr<boost::uuids::uuid> > >::_M_deallocate (
    this=0x2aaaab2cea50, __p=0x1cfd8d0, __n=8) at /opt/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.5/../../../../include/c++/4.4.5/bits/stl_vector.h:146
#7  0x000000000049598b in std::_Vector_base<boost::shared_ptr<boost::uuids::uuid>, std::allocator<boost::shared_ptr<boost::uuids::uuid> > >::~_Vector_base (
    this=0x2aaaab2cea50, __in_chrg=<value optimized out>)
    at /opt/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.5/../../../../include/c++/4.4.5/bits/stl_vector.h:132
#8  0x000000000048bf27 in std::vector<boost::shared_ptr<boost::uuids::uuid>, std::allocator<boost::shared_ptr<boost::uuids::uuid> > >::~vector (this=0x2aaaab2cea50,
    __in_chrg=<value optimized out>) at /opt/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.5/../../../../include/c++/4.4.5/bits/stl_vector.h:313
#9  0x0000003f1ee337fe in __cxa_finalize () from /lib64/libc.so.6
#10 0x00002aaaab052b36 in __do_global_dtors_aux ()
from /home/user/workspace/NewProject/build/components/lib_path/libhelper-d.so
#11 0x0000000000000000 in ?? ()

我真的不知道如何从这里开始。

更新我忘了提到出现在错误中的唯一全局变量在错误出现m_uuids.size() == 0时被清除。

4

2 回答 2

6

我在使用 glog 时遇到了同样的问题。就我而言，是这种情况：

  1. 我有一个共享库，将其称为链接 glog 的“common.so”。
  2. 我的主要可执行文件，称为“应用程序”，也链接了 glog，并链接在 common.so 中。

我遇到的问题是 glog 在 .so 和可执行文件中都是静态链接的。当我将#1 和#2 都更改为链接.so 而不是.a 时，问题就消失了。

不确定这是您的问题，但可能是。一般来说，释放内存时的损坏通常意味着您损坏了内存池（例如两次删除同一个指针）。我相信在这两种情况下都在 .a 中进行链接，我在同一个全局指针（在我的情况下是 std::string）上获得了两次清理行为。

更新：经过大量调查，这很可能是问题所在。发生的情况是每个可执行文件和 .so 都有一个 std::string 类型的全局变量（glog 的一部分）。当动态链接器/加载器加载对象（exe、.so）时，必须构造这些 std::string 全局变量。此外，使用at_exit添加了每个析构函数以进行清理。但是，当调用at_exit函数时，两个全局引用都指向同一个 std::string。这意味着 std::string 析构函数被调用两次，但在同一个对象上。然后免费在同一内存位置调用两次。全局 std::string （或任何具有构造函数的类）是一个坏主意。如果您选择使用基于 .so 的架构（一个好主意），则必须小心所有 3rd 方库以及它们如何处理全局变量。通过链接到所有 3rd 方库的 .so，您可以避免最大的危险。

于 2014-05-06T16:00:33.700 回答
1

出现错误的地方可能有点误导。我最好的猜测是你有一个共享指针向量，当它被销毁时，其中一个（至少）共享指针试图删除它指向的对象，却发现它已经被删除.

您是否在任何地方将原始指针与共享指针混合在一起？如果是这样，您可能会在某个地方发现一个完全无害的外观delete，它正在从您的脚下拉扯地毯shared_ptr

于 2012-11-05T14:44:32.577 回答