Мне нужно проверить утечку памяти во встроенную систему.утечка памяти во встроенной системе
IDE - это HEW, и мы используем uCOSIII RTOS.
Valgrind не поддерживает вышеуказанные конфигурации. Можете ли вы предложить инструмент или метод проверки утечек памяти?
Ваше требование не совсем ясно. Если вы ищете инструмент как «valgrind», который может найти утечку памяти в вашей среде; это трудно понять.
Если у вас есть код, вы можете проверить все распределения памяти &, освобождая память в конкретном приложении. Как link1Link2
Также есть некоторые файлы, доступные при их выполнении, вы можете обнаружить утечку памяти.
http://code.axter.com/debugalloc.cpp
http://code.axter.com/debugalloc.h
http://code.axter.com/debuglogger.cpp
http://code.axter.com/debuglogger.h
http://code.axter.com/debuglog.c
http://code.axter.com/debuglog.h
debugalloc. * Код имеет возможность отслеживать утечки памяти, и она имеет описание и использования информации в комментариях.
debuglogger. * Код имеет код для профилирования вашего кода.
debuglog. * Есть некоторые ограниченные версии кода C.
Первое правило динамического распределения памяти во встроенных системах - «не делать». Выделите все это один раз в начале исполнения, а затем оставите в покое. В противном случае вы должны оценить и решить, что делать, если сбой malloc (или аналогичная операция).
Если вам необходимо динамически распределять память во время выполнения, то при ее простейшем использовании вы можете использовать инфраструктуру регистрации для отслеживания вызовов до malloc/free путем написания оберток вокруг них. Затем вы можете отслеживать, где и когда происходит распределение и освобождение, и, надеюсь, увидеть, чего не хватает.
Взгляните на libtalloc, распределитель основной памяти, используемый в Samba. Он может не работать из-за-коробки для вас, если у вас нет atexit() или stdio.h, но не стоит слишком много работать, чтобы перенести его в вашу среду.
Посмотрите на talloc_enable_leak_report_full() и talloc_report_full() (среди других), чтобы вы начали.
У меня возникли некоторые мысли об этом, и вот случайная попытка сделать это со встроенными системами: * Сначала вам нужно проверить, какая утечка потока происходит. При выполнении alloc вы также должны подсчитывать для каждого потока количество активных распределений. Если количество распределений продолжает расти без освобождения, это подозрительная задача. * Во-вторых, вам нужно подсчитать количество распределений для распределений, исходящих из этого потока. Для этого замените alloc макросом. Используя макрос, вы можете сохранить имя файла и номер строки, в которой был вызван вызов.
, например
#define alloc(x) my_alloc(x, __LINE__, __FILE__)
void * my_alloc(size_t size, int line, char * file)
{
// increase number of allocations and dealocations for each combination line/file
}
Аналогично вам нужно определить my_free.
После этого запустите программу и распечатайте время от времени распределения, которые продолжают расти. Это должно помочь найти утечки памяти.
P.S. Я не тестировал это, но видел, что кто-то делает что-то подобное в нашем коде :)
Помимо обработки несостоявшегося malloc, вы также должны учитывать тот факт, что malloc не является детерминированной операцией. Другими словами, количество времени, которое malloc берет, может меняться от одного вызова к следующему и, как таковое, может привести к пропущению крайних сроков реального времени ... –
@ChrisDesjardins - отличная точка –