rdb_devТы не понял моего намёка на барьеры памяти. Используешь boost для обеспечения атомарности при работе с данными в разделяемой между потоками памяти?
Намек я понял, но не использую ни boost, ни std::shared_ptr, у меня свое казино с блэкджеком и путанами :)

Я не оценил необходимости в данных библиотеках и классах, но есть схожие механизмы, которые работают не хуже. Баг нужно локализовать и исправить и все будет работать нормально, закидывать место exception'ами или закручиванием в разделяемый ресурс с подсчетом ссылок в данном случае равносильно сокрытию более суровых багов, так что, пока, кроме механизма распараллеливания и сбора данных от потоков, все устраивает.

kealon(Ruslan)адекватный у тебя стэк - не ищи того чего нет, как раз вызовы виртуальных функций на удалённом и выделенном объекте, слова ниже это подтверждают
ну и замечательно :),
будем двигаться дальше

Anatoly MoskovskyКстати, то что удалось достичь 100% повторяемости, говорит о том что речь не о гонках из-за многопоточности.
А это дополнительно повышает вероятность того что проблема вызвана конструктором копирования.

Увы, не мой случай

За долгое время работы я уже выработал привычку принудительно запрещать подобное во всех своих классах, в которых мне такое поведение не нужно, объявляя конструктор как private.

Причину проблемы я установил, и она заключается в том, что в очень редких случаях (отсюда и долговременность работы приложения и хаотичность падений) в классе пула потоков происходит следующая ситуация: клиент создает массив запросов CPoolTask и помещает их на обработку в пул потоков (QueryFarm), пул создает необходимые потоки или пробуждает простаивающие и приступает к обработке новых заданий. Потоки, которыми управляет пул, если для них нет работы в течение длительного времени, могут запросить у пула подтверждение на завершение своей работы, и пул, в зависимости от его настройки, может им это разрешить. Когда пул разрешает объекту потока завершить себя, тот вычищает свою память, включая хранимое в нем задание CPoolTask, если таковое имеется и клиент (!), поставивший это задание на обработку, тоже не против такого поведения. Я настроил пул так, чтобы он не чистил задания автоматически, но как оказалось не везде: выход потока по таймауту я не предвидел.

Пул разрешил потоку завершить себя, а раз клиент тоже не отреагировал на запрос об удаление объекта CPoolTask, то поток добросовестно прихватил и его. Это тот самый первый раз, когда объект задания удален правильно, с точки зрения кучи, но об этом ничего не известно в классе клиента, который это задание туда назначал. Поэтому когда приходит момент почистить задания на клиенте я и получаю double-free.

Anatoly MoskovskyЕсли у вас объект одновременно используется в нескольких местах, то используйте shared_ptr и не морочьте себе голову всякими разрешениями на удаление.
возможно, что и буду, но, если бы я его использовал, то никогда бы не понял, что возможна такая ситуация:



не знаю сколько бы времени я еще угрохал на то, чтобы понять почему у меня запросы зависают и не обрабатываются :), а так найден логический баг, который можно поправить