Приветствую.
Столкнулся с проблемой, которую даже не знаю как адекватно сформулировать, поэтому сейчас будет поток сознания. Если коротко: программа падает.
Подробнее.
Повсеместно используются умные указатели (std::shared_ptr и std::unique_ptr). Имеется некоторая вложенность объектов, которая примерно выглядит так:
, где Job наследуется от boost::noncopyable.

Усугубляется это безобразие тем, объекты shared_ptr<Job> создаются в коде библиотеке, загружаемой во время выполнения и в сам контейнер попадают не сразу же, а пройдя еще через некоторые методы-объекты-контейнеры.
В общем, не вижу смысла приводить тут весь код: никто в здравом уме не будет разбираться во всей системе. В то же время не удалось написать короткий пример для воспроизведения проблемы.

Собственно, вопрос: если кто-нибудь сталкивался с падениями при использвании умных указателей, как вообще подходить к отладке и на что смотреть? 
Максимум, что я понял из бэктрейса, падение происходит где-то в деструкторе Queue при уничтожении его контейнера шаред поинтеров. Все дальнейшее мне мало о чем говорит, но все-таки ниже приложу сам бэктрейс.

В деструкторе Queue пробегался по всем объектам из контейнера и смотрел use_count - везде единички.

Временное решение проблемы - вектор указателей заменить на вектор объектов, для Job убрать наследование от boost::noncopyable. 

Бэктрейс:


Это сообщение отредактировал(а) ChipNDale - 13.2.2013, 17:36

Библиотека откомпилирована тем же компилятором, что и основное приложение ? С теми же опциями компиляции ? С теми же STL-ными h-никами ?

Да, тут весь код свой, в одном "солюшне", соответственно компилятор один и его флаги задаются глобально в единственном месте.

Добавлено @ 18:03
Эм... Сейчас наугад удалил одну строчку, внезапно сегфолт пропал.
Детали такие:
Job находится в библиотеке, которая статически линкуется с основным приложением.
Приложение во время выполнения загружает динамическую библиотеку из которой получает фабрику для этих Job'ов.
А убрал я закрытие библиотеки с этой самой фабрикой. Т.е. закрывать-то ее по-хорошему, надо, но, кажется, что если это происходит до уничтожения объекта Job, то происходит такое падение. И мне пока не ясно почему так.

Upd: проверил теорию. Да, если сначала уничтожить все созданные объекты, а только потом закрыть загруженные библиотеки, то работает корректно. Но вопрос "почему так происходит" все еще актуален.

Это сообщение отредактировал(а) ChipNDale - 13.2.2013, 18:11

Вот такой получился пример для воспроизведения.
main.cpp:


factory.cpp:


Компиляция:


Запуск:

есть простое правило, кто создал, тот удаляет..   

подозреваю, что если в DLL'ке CRT используется, как статическая библиотека, то и куча создаётся на эту DLL'ку, и умирает с её выгрузкой

если же CRT используется, как DLL всеми модулями, думаю, одной причиной для падения будет меньше

Добавлено через 1 минуту и 9 секунд
хм... перечитал, понял, что не для Visual Studio, но для другой платформы/инструментов может тоже такое быть

Если бы использовались разные компиляторы или несогласованные способы выделения/освобождения памяти, то согласен - это поможет защититься. В моем же случае таких разногласий нет и я использую смарт поинтеры как раз для того, чтобы не приходилось следить за временем жизни каждого отдельного объекта.



Вероятно, что-то такое и происходит. А можно ли с помощью чего-нибудь посмотреть и получить более-менее наглядную картину? (а пока попробую потерзать гугл сомнительными запросами)

Посмотрите objdump'ом и ldd, где находятся new/delete/malloc/free в основной программе и в .so модуле. Если они у каждого локальные - будут проблемы. Если берутся из одной и той же внешней .so - то проблем быть не должно
Еще можно глянуть в реализацию shared_ptr<> - что именно используется для удаления объекта (подозреваю, что банальный delete, но кто знает ... )