升压:可能是什么原因,在boost崩溃::插槽<> ::〜插槽? [英] Boost: what could be the reasons for a crash in boost::slot<>::~slot?

查看:325
本文介绍了升压:可能是什么原因,在boost崩溃::插槽<> ::〜插槽?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我收到这样的崩溃:

#0  0x90b05955 in __gnu_debug::_Safe_iterator_base::_M_detach
#1  0x90b059ce in __gnu_debug::_Safe_iterator_base::_M_attach
#2  0x90b05afa in __gnu_debug::_Safe_sequence_base::_M_detach_all
#3  0x000bc54f in __gnu_debug::_Safe_sequence_base::~_Safe_sequence_base at safe_base.h:170
#4  0x000aac05 in __gnu_debug::_Safe_sequence<__gnu_debug_def::vector<boost::signals::trackable const*, std::allocator<boost::signals::trackable const*> > >::~_Safe_sequence at safe_sequence.h:97
#5  0x000ac9c1 in __gnu_debug_def::vector<boost::signals::trackable const*, std::allocator<boost::signals::trackable const*> >::~vector at vector:95
#6  0x000acf65 in boost::signals::detail::slot_base::data_t::~data_t at slot.hpp:32
#7  0x000acf8f in boost::checked_delete<boost::signals::detail::slot_base::data_t> at checked_delete.hpp:34
#8  0x000b081e in boost::detail::sp_counted_impl_p<boost::signals::detail::slot_base::data_t>::dispose at sp_counted_impl.hpp:78
#9  0x0000a016 in boost::detail::sp_counted_base::release at sp_counted_base_gcc_x86.hpp:145
#10 0x0000a046 in boost::detail::shared_count::~shared_count at shared_count.hpp:217
#11 0x000a9fb0 in boost::shared_ptr<boost::signals::detail::slot_base::data_t>::~shared_ptr at shared_ptr.hpp:169
#12 0x000aa459 in boost::signals::detail::slot_base::~slot_base at slot.hpp:27
#13 0x000aad07 in boost::slot<boost::function<bool ()(char, int)> >::~slot at slot.hpp:105
#14 0x001b943b in main at vermes.cpp:102

这是code:

#include <boost/signal.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/function.hpp>
#include <boost/bind.hpp>

bool dummyfunc(char,int) { return false; }

int main(int argc, char **argv)
{   
    boost::signal<bool (char, int)> myslot;
    myslot.connect(0, &dummyfunc);
    return 0;
}

这是我第一次与升压工作,我也完全地新项目,我想在这里端口的code。

It's the first time I am working with Boost and I am also completly new to the code of the project I am trying to port here.

这就是为什么我想问一下,如果这样的崩溃可能是由升压解释任何方式或是否必须是无关的推动作用。

That is why I would like to ask if such a crash could be in any way explained by Boost or if it must be unrelated to Boost.

我已经试图了解坠机本身,而是我被莫名其妙地卡住了。看来,可能是性病::载体,是要在这里删除,被搞砸了(搞砸=内存损坏)。该矢量是slot_base :: data_t的成员。缺失在slot_base :: shared_ptr的析构函数完成。因此,或许还的shared_ptr被搞砸了 - 所以甚至整个slot_base一塌糊涂。但在code我有,我真的不明白了一个道理,为什么内存可能会混乱。它甚至myslot施工后所有的第一次访问。

I already tried to understand the crash itself but I got stuck somehow. It seems that probably the std::vector, which is going to be deleted here, is messed up (messed up = memory corrupt). That vector is a member of slot_base::data_t. The deletion is done in the destructor of slot_base::shared_ptr. So perhaps the shared_ptr also was messed up - so perhaps even the whole slot_base was messed up. But in the code I have, I don't really see a reason why that memory could be messed up. It is even the first access at all after the construction of myslot.

增加:我也真的不明白是为什么,当我做了连接〜slot_base()在此被称为在所有。但我也没发现的Connect-memberfunction。那是一个神奇的地方万客隆?

Addition: What I also don't really understand is why the ~slot_base() is called here at all when I do the connect. But I also didn't found the connect-memberfunction. Is that a magic makro somewhere?

推荐答案

我发现这个问题。当我启用这些preprocessor定义(我的X code这是否在调试配置缺省值),它崩溃:

I found the problem. When I enable these preprocessor definitions (my Xcode does that by default in Debug configuration), it crashes:

-D _GLIBCXX_DEBUG=1
-D _GLIBCXX_DEBUG_PEDANTIC=1

我想没有那些编译升压(bjam的),并导致这样的问题,因为当有或没有这个编译STL结构(如矢量)外观以二进制形式不同。

I guess Boost (bjam) compiled without those and that causes such problems because the STL structures (like vector) look different in binary form when compiled with or without this.

这篇关于升压:可能是什么原因,在boost崩溃::插槽&LT;&GT; ::〜插槽?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆