Boost: boost::slot<>::~slot 崩溃的原因可能是什么?

发布于 2024-08-13 00:10:59 字数 2348 浏览 5 评论 0 原文

我遇到了这样的崩溃:

#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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

煞人兵器 2024-08-20 00:10:59

我发现了问题。当我启用这些预处理器定义时(我的 Xcode 在调试配置中默认执行此操作),它会崩溃:

-D _GLIBCXX_DEBUG=1
-D _GLIBCXX_DEBUG_PEDANTIC=1

我猜 Boost (bjam) 编译时没有这些定义,这会导致此类问题,因为编译时 STL 结构(如向量)在二进制形式中看起来不同有或没有这个。

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

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.

柳絮泡泡 2024-08-20 00:10:59

听起来您的 GConsole 类不是从 boost::trackable 派生的。

当信号绑定到成员函数时,它期望成员的对象始终存在。

您可以在成员函数的所有者被销毁时显式断开信号,也可以从 boost::trackable 派生对象,这将在对象被销毁时自动进行维护。

It sounds like your GConsole class is not derived from boost::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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文