Объекты, которые выживают до завершения процесса, не обязательно являются утечками памяти, и инструмент не сможет сказать вам, какие из них утечки памяти, а какие нет. Утечки памяти - это обычно только те выделения, которые выполняются несколько раз из одного и того же расположения программы и никогда не освобождаются. Даже тогда, это не всегда так. Обнаружение утечек требует специального тестового жгута, который повторяет серию операций, которые, как предполагается, не оставляют память, выделенную в любом заданном местоположении программы, более одного раза. Если затем вы заметите, что с увеличением количества операций количество оставшихся блоков памяти увеличивается, вы, вероятно, испытываете настоящую утечку. В идеале тестовый жгут должен делать снимки выделенных блоков памяти после каждого «рабочего цикла» и отмечать места программы, которые постоянно оставляют позади вещи. Библиотека должна быть в состоянии захватить трассировку стека, чтобы указать местоположение программы, в которой было выполнено выделение. В противном случае на практике это бесполезно.
Я очень подозрительно отношусь к коду, который освобождает всю память перед завершением процесса: обычно это просто пустая трата времени, продление времени остановки системы и просто плохой UX. Когда пользователь нажимает кнопку «Выход», убедитесь, что данные в безопасности (например, закройте файлы sqlite, сохраните открытые документы - возможно, просто как «незавершенную работу», которая будет возвращена при следующем использовании приложения), а затем call exit(0)
.
В общем, обнаружение утечек занимает немного больше, чем просто использование библиотеки, которая дает вам список блоков памяти, выделенных при выходе. Библиотека - это инструмент, который вы, мыслящий, рассудительный разработчик, должны применить к проблеме :) Точно так же, как молоток не будет полезен, если бить его повсюду (если у вас нет большого количества гвоздей, чтобы забивать!), поэтому не будет библиотеки «детектор утечки» сама по себе.