Я хочу попробовать некоторые инструменты статического анализа с открытым исходным кодом, чтобы проверить их производительность при обнаружении утечек в исходном коде Linux. Я начинаю с cppchecker.
В Linux большинство вызовов выделения памяти выполняются с помощью таких функций, как kmalloc (), kzalloc (), и соответствующей свободной функцией является kfree (). Как я могу настроить cppchecker для отслеживания вызовов kmalloc вместо вызова по умолчанию malloc ()? Существует нечто, называемое созданием нового конфигурационного файла, в котором мы можем определить предпочтения пользователя, но я не могу понять, как это сделать.
Также в качестве продолжения вышеуказанного вопроса выполняет ли cppcheck межпроцедурный анализ для обнаружения утечек памяти? Какие другие инструменты статического анализа с открытым исходным кодом я могу использовать для этой цели?
Я разработчик Cppcheck.
Это правда, что есть старая встроенная обработка для kmalloc и т. Д. Хорошим началом является проверка ядра со встроенными знаниями. Файл CFG не требуется.
Однако с помощью файла cfg вы можете улучшить cppcheck.
Вот начало:
<?xml version="1.0"?>
<def format="1">
<memory>
<dealloc>kfree</dealloc>
<alloc init="false">kmalloc</alloc>
<alloc init="true">kzalloc</alloc>
</memory>
</def>
Сохраните этот текст в файле с именем, например kernel.cfg, а затем используйте, например, —library = kernel, чтобы использовать эту информацию во время анализа cppcheck.
В этом cfg много недостающей информации. Если вы используете —check-cfg, Cppcheck будет жаловаться, когда он сбит с толку во время анализа и хочет больше информации о cfg. Это в основном нуждается в noreturn информации о функциях, а также, если функция «игнорирует утечку».
Вы можете посмотреть в нашем официальном файле std.cfg, например, на конфигурацию для strcmp (). Эта конфигурация явно говорит о том, что strcmp () не noreturn. Конфигурация также имеет атрибут «leak-ignore» — потому что если вы можете передать указатель на выделенную память в strcmp (), то средство проверки утечек должно игнорировать это, потому что strcmp () не вызовет никакого освобождения и т. Д.
Дайте нам знать, если у вас есть вопросы о том, как это работает.
Вы совершенно уверены, что cppcheck еще не может проверить наличие утечек при выделении ядра? Исходный код выглядит так, как будто он обрабатывает kmalloc и так далее, как malloc. Посмотрите, например, на файл testmemleak.cpp в репозитории cppcheck, и вы увидите тестовые примеры, которые используют неверный kmalloc.
Что касается межпроцедурного анализа, я не верю, что cppcheck делает это. Я предполагаю, что GCC мог бы сделать немного, основываясь на флаге -flto, но я не эксперт.