Задача ослеживания утечек памяти.

Привет! Есть такая задача:
В некой точке А программы выделяем память под структуры
в точке Б удаляем(думаем, что удаляем) все структуры
в точке С нужно проверить вся ли память выделенная под структуры
в точек А была освобождена. Нужно знать в точности до байта.
Есть ли простые способы для этого мониторинга? На С, конечно.
Может случится следующий сценарий:
Все указатели на структуры показывают на NULL. Но память у одной или нескольких не освобождена.

 

Нашел кажется кое-что интересное
http://www.codeguru.com/forum/showthread.php?t=312742
Оцените, коллеги.

 

Я обычно проверяю, цикличиски прокручивая участки кода, если вижу что растет размер потребляемой памяти, пересматриваю все malloc\free.

То что по ссылке, там предлагают использовать класс с деструктором который освободит память, это уже С++.

PS Пишите лучше хороший и качественный код без memory leak, либо переходите на java.

 

Как определяете, что растет потребляемая память?

 

в этой части:
_CrtMemState s1, s2, s3;

_CrtMemCheckpoint( &s1 );
// memory allocations take place here
_CrtMemCheckpoint( &s2 );

if ( _CrtMemDifference( &s3, &s1, &s2) )
_CrtMemDumpStatistics( &s3 );

Нет никакого С++

На жабе тоже можно навыделять объектов, которые будут болтаться без дела, так как до garbage collector дело может не дойти. По GC есть даже целая книга(очень толстая) для программеров C#. Раз я сделал прогу на шарпе отожрала 500 метров, но работала благо комп был мощный.

 

В диспетчере задач

 

в килобайтах? Не очень аккуратно. ...И опрометчиво.

 

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

 

DevParnter/AQTime/Intel Parallel Studio/Deleaker и тп

 

Попробуй Visual Leak Detector

http://habrahabr.ru/blogs/cpp/113567/

 

возможно, оптимальным способом будет использование

http://www.hpl.hp.com/personal/Hans_Boehm/gc/
http://en.wikipedia.org/wiki/Boehm_garbage_collector

в инклудах к нему есть хидера подменяющие стандартные маллокеры, включая new для С++

для линей может быть использован http://valgrind.org/

ну и случаи когда

struct A {
struct A* p;
} a, b, c, d;

a.p = &b;
b.p = &c;
c.p = &d;
d.p = &a;

вообще плохо поддаются детекции.

 

neutronion
Чем не устраивает решение в лоб?

Ну вот как-то примерно так

Код (Text):

1. typedef struct
2. {
3.     void* ptr;
4.     size_t bytes;
5. } allocation;
6.  
7. unsigned maxAllocs = 1024;
8. allocation* allocs;
9.  
10. void _start()
11. {
12.     if (allocs != NULL)
13.         return;
14.    
15.     if ((allocs = (allocation*) calloc (sizeof(allocation), maxAllocs)) == NULL)
16.         return;
17. }
18.  
19. void _stop()
20. {
21.     unsigned i;
22.    
23.     if (allocs == NULL)
24.         return;
25.    
26.     for (i = 0; i < maxAllocs; ++i)
27.     {
28.         if (allocs[i].ptr != NULL)
29.         {
30.             printf("MEMORY LEAK: %d bytes allocated at %p was not freed within the control region\n",
31.                 allocs[i].bytes, allocs[i].ptr);
32.         }
33.     }
34.    
35.     free (allocs);
36.     allocs = NULL;
37. }
38.  
39. void* _malloc (size_t byteCount)
40. {
41.     void* p;
42.    
43.     if ((p = malloc (byteCount)) != NULL)
44.     {
45.         unsigned i;
46.        
47.         // add synchronization for safe multithread access
48.        
49.         for (i = 0; i < maxAllocs; ++i)
50.         {
51.             if (allocs[i].ptr == NULL)
52.             {
53.                 allocs[i].ptr = p;
54.                 allocs[i].bytes = byteCount;
55.                
56.                 return p;
57.             }
58.         }
59.        
60.         // no free slots
61.         free (p);
62.     }
63.    
64.     return NULL;
65. }
66.  
67. void _free (void* p)
68. {
69.     unsigned i;
70.    
71.     // add synchronization for safe multithread access
72.  
73.     for (i = 0; i < maxAllocs; ++i)
74.     {
75.         if (allocs[i].ptr == p)
76.             allocs[i].ptr = NULL;
77.     }
78.  
79.     free (p);
80. }
81.  
82. #define malloc(bc)    _malloc(bc)
83. #define calloc(x,y)   _malloc(x*y)
84. #define free(p)       _free(p)

 

мне кажется, что лучше при аллокации добавлять к выделенной памяти хедер, объединяющий все аллоки в двусвязный список, а юзеру возвращать prt + sizeof(header)... так можно избежать проблем с максимальным числом аллоков, и обойтись одной статической переменной lastalloc...

 

Rel

void* _malloc(int len){
void* p = malloc(len + sizeof(header));
((header*)p)-> ... // устанавливаем хидер

return p + sizeof(header);
}

char* a = _malloc(len_of_string);

a[-3] = .. // пишем чтото

---
речь ведь идет о поиске ошибки, правда? почему не допустить что она изза анормальной деятельности программы?

 

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

 

Чем плох этот вариант в тестировании.

Код (Text):

1. _CrtMemState s1, s2, s3;
2.  
3. _CrtMemCheckpoint( &s1 );
4. // здесь делаем выделения памяти и освобождение
5. _CrtMemCheckpoint( &s2 );
6.  
7. if ( _CrtMemDifference( &s3, &s1, &s2) )
8. {
9.     //если попали сюда, значит утечка
10.    _CrtMemDumpStatistics( &s3 );
11. }

По-моему проще. 4 строки кода.
Речь в принципе идет о том, чтобы в процессе изготовления кода, тестировать его блочно на предмет утечек памяти, сначала мелкие функции , потом крупные части, которые используют уже оттестированные функции.
Такая идея. Вопрос в том, может ли вышеописанная конструкция детектирования утечек подвести в каком-нибудь сценарии.

 

Rel

вол так и делает. хотя нет, там все сложнее. там используется перетрансляция кода и контроль над каждым обращением к памяти + общий контроль при уходах в ядро.

но боехм позволяет все это решить гораздо проще. без необходимости чтото переписывать или особо изучать.

 

Вот для простоты

Код (Text):

1. _CrtMemState s1, s2, s3;
2.  
3. void StartLeakDetection()
4. {
5.          //s1, s2, s3; надо бы здесь их обнулить
6.     _CrtMemCheckpoint( &s1 );
7. }
8.  
9. bool StopLeakDetection()
10. {
11.     _CrtMemCheckpoint( &s2 );
12.     if ( _CrtMemDifference( &s3, &s1, &s2) )
13.     {
14.         //leak!!!!!
15.         return false;
16.     }
17.     return true;
18. }
19.  
20.  
21. void Main()
22. {
23.     StartLeakDetection();
24.  
25.     //здесь делаем выделения и освобождения
26.    
27.     if(true != StopLeakDetection())
28.     {
29.         //утечка!!!!
30.     }
31.  
32.  
33. }

 

есть такой интересный подход, выделяем память,но в первые 4 байта выделенной памяти пишем магическое число. Соответственно выделяем памяти на 4 байта больше чем необходимо, чтобы особо не утруждаться можно писать это маг. число в конец. Кроме того можно будет проверить выделенную память, когда эта память еще не возвращена системе, если не
находим магическое число, кто-то его уже покоцал. Перед освобождением памяти перезаписываем эту область памяти нулями. Затем освобождаем.
После сканируем память на предмет магических чисел. Если что-то нашли, значит не вся память была возвращена системе. У кого-то умного прочитал, не помню у кого.
Кажется Code complete(Совершенный код) книжка.

 

neutronion

в процессе расчетов в памяти появились целые острова магических чисел. не относящихся к подобной защите. просто некоторые значения равные магическому числу.