Утечка Mock объектов при использовании GoogleMock вместе с Boost :: Shared Pointers
По этому особому сценарию я не могу избавиться от утечек.
При выполнении теста я получаю сообщение об объектах Leaked Mock. Конкретное сообщение:
ClassElementFixture.h: 102: ОШИБКА: этот фиктивный объект (используемый в тесте ClassElementFixture.initialize) должен быть удален, но никогда не удаляется. Его адрес @ 0x940a650.
Я отметил строку, к которой относится ошибка.
Вот упрощенная версия моего кода:
...
class ClassElementFixture: public ::testing::Test
{
public:
boost::shared_ptr<fesa::ClassElement> classElement_;
boost::shared_ptr<fesa::DeviceElementMock> deviceElement_;
...
void SetUp()
{
classElement_.reset(new fesa::ClassElement());
}
void TearDown()
{
}
void initializeFake()
{
fesa::ParserElementFactoryMock factory;
deviceElement_.reset(new fesa::DeviceElementMock());
EXPECT_CALL(factory, createDeviceElement(_))
.WillOnce(Return(deviceElement1_));
EXPECT_CALL(*deviceElement_, initialize(_));//Error refers to here
classElement_->initialize(factory);
EXPECT_TRUE(Mock::VerifyAndClearExpectations(deviceElement_.get()));
}
}
Я уже нашел
Почему GoogleMock пропускает мой shared_ptr?
в стек-переполнение, что связано. Однако предложения оттуда не решают мою проблему: X
Единственная возможность, которую я нашел, чтобы хотя бы подавить ошибку:
Mock::AllowLeak(deviceElement_.get());
Однако это не очень чистое решение =)
Так как правильно избавиться от утечек?
Решение
Если вы используете умные указатели, вам все равно нужно иметь четкое представление о владении, иначе вы можете получить низкую производительность, циклические зависимости и утечки памяти.
Я предлагаю выбор умного указателя по умолчанию должен быть unique_ptr для уникального владения и использования сырых указателей для наблюдателей.
Если наблюдатели могут потенциально пережить владельца, тогда переходите к одному shared_ptr для владельца и weak_ptr для наблюдателей.
Используйте только «общий» shared_ptr в крайнем случае, когда у вас нет одного явного владельца и будьте осторожны с циклическими зависимостями.
Другие решения
Не используйте общие указатели. Или, если вам действительно нужно использовать их, убедитесь, что они возвращаются к 0 и уничтожаются в конце теста.
Это старый вопрос, но я не вижу никого, кто бы упоминал только что найденное решение.
Я видел ту же ошибку, пока не добавил виртуальный деструктор в класс, над которым я издевался. В вашем случае убедитесь, что у вас есть виртуальный деструктор в ParserElementFactoryMock. Имеет смысл, так как без виртуального деструктора фиктивный объект не освободит свои ресурсы при выходе из области видимости.