Обнаружение конкретных вызовов функций в модульных тестах

Модульные тесты вызывают функции, которые они тестируют. Вы хотите знать, может ли функция F, вызываемая модульным тестом, в конечном итоге вызвать malloc (или new, или...). Похоже, что вы действительно хотите построить граф вызовов для всей вашей системы, а затем запросить критические функции F, может ли F достичь malloc и т. д. в графе вызовов. Это довольно легко вычислить, если у вас есть граф вызовов.

Получить график вызовов не так просто. Обнаружение того, что модуль A вызывает модуль B напрямую, «технически просто», если у вас есть реальный языковой интерфейс, который выполняет разрешение имен. Выяснить, что A вызывает косвенно, непросто; вам нужен (указатель функции) указывает на анализ, и это сложно. И, конечно же, вам решать, собираетесь ли вы погрузиться в библиотечные (например, std::) подпрограммы или нет.

Ваш график вызовов должен быть консервативным (чтобы вы не пропустили потенциальные вызовы) и достаточно точным (чтобы вы не утонули в ложных срабатываниях) перед лицом указателей на функции и вызовов методов.

Эта поддержка Doxygen утверждает, что строит графики звонков: http://clang.llvm.org/doxygen/CallGraph_8cpp.html Я не знаю, обрабатывает ли он косвенные вызовы/вызовы методов и насколько он точен; Я не очень хорошо знаком с этим, и документация кажется тонкой. В прошлом Doxygen не славился хорошей обработкой косвенности или точностью, но прошлые версии не были основаны на Clang. Существует некоторое дальнейшее обсуждение этого применения в небольших масштабах по адресу http://stackoverflow.com/questions/5373714/generate-calling-graph-for-c-code

Ваш вопрос помечен как c/c++, но, похоже, он касается C++. Для C — наш инструментарий для реинжиниринга программного обеспечения DMS с общим анализом потока и графиком вызовов. Поддержка генерации в сочетании с C Front End от DMS была используется для анализа систем C, содержащих около 16 миллионов строк/50 000 функций с косвенными вызовами для создания консервативно правильных графов вызовов.

Мы специально не пытались строить графы вызовов C++ для больших систем, но тот же общий анализ потока DMS и генерация графа вызовов были бы «технически простыми», используемыми с Внешний интерфейс C++. При построении статического анализа, который работает правильно и в масштабе, нет ничего тривиального.

Если вы используете библиотеки, которые вызывают malloc, вам может понадобиться взглянуть на Стандарты программирования C++ для Joint Strike Fighter. Это стиль кодирования, направленный на критически важное программное обеспечение. Одним из предложений было бы написать свой собственный распределитель (ы). Другое предложение состоит в том, чтобы использовать что-то вроде jemalloc, у которого есть статистика, но оно гораздо более непредсказуемо, поскольку оно ориентировано на производительность.

То, что вам нужно, это издевательская библиотека со шпионскими возможностями. То, как это работает для каждой платформы, будет отличаться, но вот пример с использованием Google:

static std::function<void*(size_t)> malloc_bridge;

struct malloc_mock {
    malloc_mock() { malloc_bridge = std::bind(&malloc_mock::mock_, this, _1); }
    MOCK_METHOD1(mock_, void*(size_t));
}

void* malloc_cheat(size_t size) {
    return malloc_bridge(size);
}

#define malloc malloc_cheat

struct fixture {
    void f() { malloc(...); }
};

struct CustomTest : ::testing::test {
    malloc_mock mock_;
};

TEST_F(CustomTest, ShouldMallocXBytes) {
    EXPECT_CALL(mock_, mock_(X))
      .WillOnce(::testing::Return(static_cast<void*>(0)));
    Fixture fix;
    fix.f();
}

#undef malloc

ВНИМАНИЕ: код не был затронут компилятором. Но ты получил идею.

Это не полный ответ, но вы можете попробовать использовать Valgrind для подсчета распределений и освобождений. Инструмент Valgrind по умолчанию memcheck по умолчанию подсчитывает количество распределений и освобождений и печатает результирующий отчет в HEAP SUMMARY, вот пример вывода:

$ valgrind ./a.out
==2653== Memcheck, a memory error detector
==2653== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2653== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2653== Command: ./a.out
==2653== 
==2653== 
==2653== HEAP SUMMARY:
==2653==     in use at exit: 0 bytes in 0 blocks
==2653==   total heap usage: 2 allocs, 2 frees, 72,716 bytes allocated
==2653== 
==2653== All heap blocks were freed -- no leaks are possible
==2653== 
==2653== For counts of detected and suppressed errors, rerun with: -v
==2653== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

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

void my_unit_test_baseline() {
    my_object obj; // perform some initialization that will allocate
}

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

В случае, если вы используете библиотеку GNU C, вы можете использовать _malloc_hook () и подобные функции, чтобы пользовательская функция вызывалась всякий раз, когда используется одна из функций семейства malloc.

Такая перехваченная функция может анализировать трассировку вызовов (используя backtrace()), чтобы выяснить, разрешен ли malloc в этой цепочке вызовов или нет, и, если нет, вывести сообщения о виновнике.