我遇到了这样的崩溃:
#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
这是代码:
#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;
}
这是我第一次使用 Boost,而且我对我试图移植到这里的项目的代码也是完全陌生的。
这就是为什么我想问这样的崩溃是否可以用 Boost 来解释,或者它是否一定与 Boost 无关。
我已经尝试了解崩溃本身,但不知怎的我陷入了困境。看起来可能要在这里删除的 std::vector 被搞乱了(搞乱了 = 内存损坏)。该向量是 slot_base::data_t 的成员。删除是在 slot_base::shared_ptr 的析构函数中完成的。所以也许shared_ptr也被搞乱了——所以也许甚至整个slot_base也被搞乱了。但在我的代码中,我并没有真正看到内存可能混乱的原因。这甚至是 myslot 建成后的第一次访问。
另外:我也不太明白为什么当我进行连接时会在这里调用 ~slot_base() 。但我也没有找到 connect-member 函数。那是某个地方的魔法宏吗?
I am getting such a crash:
#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
This is the 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;
}
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.
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.
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?
发布评论
评论(2)
我发现了问题。当我启用这些预处理器定义时(我的 Xcode 在调试配置中默认执行此操作),它会崩溃:
我猜 Boost (bjam) 编译时没有这些定义,这会导致此类问题,因为编译时 STL 结构(如向量)在二进制形式中看起来不同有或没有这个。
I found the problem. When I enable these preprocessor definitions (my Xcode does that by default in Debug configuration), it crashes:
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.
听起来您的
GConsole
类不是从boost::trackable
派生的。当信号绑定到成员函数时,它期望成员的对象始终存在。
您可以在成员函数的所有者被销毁时显式断开信号,也可以从 boost::trackable 派生对象,这将在对象被销毁时自动进行维护。
It sounds like your
GConsole
class is not derived fromboost::trackable
.When a signal is bound to a member function, it expects the member's object to exist, always.
You can either explicitly disconnect signals when member function's owner is destroyed, or you can derive the object from
boost::trackable
, which will do the maintenance automatically when the object is destroyed.