Boost: что может быть причиной сбоя в boost :: slot <> :: ~ slot? - PullRequest
0 голосов
/ 01 декабря 2009

Я получаю такой сбой:

#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. Это где-то волшебное макро?

Ответы [ 2 ]

1 голос
/ 03 декабря 2009

Я нашел проблему. Когда я включаю эти определения препроцессора (мой XCode делает это по умолчанию в конфигурации отладки), происходит сбой:

-D _GLIBCXX_DEBUG=1
-D _GLIBCXX_DEBUG_PEDANTIC=1

Я предполагаю, что Boost (bjam) скомпилирован без таковых, и это вызывает такие проблемы, потому что структуры STL (например, вектор) выглядят по-разному в двоичной форме при компиляции с этим или без него.

0 голосов
/ 01 декабря 2009

Похоже, ваш GConsole класс не является производным от boost::trackable.

Когда сигнал связан с функцией-членом, он ожидает, что объект-член всегда существует.

Вы можете либо явно отключить сигналы, когда владелец функции-члена уничтожен, либо вы можете извлечь объект из boost::trackable, который будет выполнять техническое обслуживание автоматически при уничтожении объекта.

...