Ошибки Valgrind, хотя все блоки кучи были освобождены - PullRequest
14 голосов
/ 28 сентября 2010

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

Для моего последнего пробега valgrind -v дал мне:

All heap blocks were freed -- no leaks are possible

Это означает, что моя программа покрыта для утечек памяти , верно?

Так что означает эта ошибка? Моя программа неправильно читает определенные блоки памяти?

ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 14 from 9)

1 errors in context 1 of 1:
Invalid read of size 4
   at 0x804885B: findPos (in /home/a.out)
   by 0xADD918: start_thread (pthread_create.c:301)
   by 0xA26CCD: clone (clone.S:133)
 Address 0x4a27108 is 0 bytes after a block of size 40 alloc'd
   at 0x4005BDC: malloc (vg_replace_malloc.c:195)
   by 0x804892F: readInput (in /home/a.out)
   by 0xADD918: start_thread (pthread_create.c:301)
   by 0xA26CCD: clone (clone.S:133)

used_suppression:     14 dl-hack3-cond-1

Кроме того, каковы здесь так называемые "скрытые" ошибки?

Ответы [ 4 ]

21 голосов
/ 28 сентября 2010

Это кажется очевидным ... но, возможно, стоит отметить, что сообщение "no leaks are possible" не означает, что ваша программа не может утечь; это просто означает, что он не протекает в конфигурации, в которой он был протестирован.

Если я запускаю следующее с valgrind без параметров командной строки, он сообщает мне, что утечки невозможны. Но это произойдет, если я предоставлю параметр командной строки.

int main( int argc, char* argv[] )
{
   if ( argc > 1 )
      malloc( 5 );
   printf( "Enter any command line arg to cause a leak\n" );
}
12 голосов
/ 28 сентября 2010
  1. Да, вы хорошо охвачены, не думайте, что valgrind легко может пропустить утечку в коде пользователя
  2. ваша ошибка означает, что вы, вероятно, имеете ошибку +1 при индексации переменной массива.строки, которые valgrind говорит вам, должны быть точными, поэтому вы легко можете найти это при условии, что вы компилируете весь свой код с -g
  3. подавленными ошибками, как правило, из системных библиотек, которые иногда имеют небольшие утечки или неопределяемые вещи, напримерпеременные состояния потоков.Ваша страница руководства должна перечислить файл подавления, который используется по умолчанию
1 голос
/ 28 сентября 2010

Проверка на утечки памяти является одной из причин использования valgrind, но я бы сказал, что лучшая причина - найти более серьезные ошибки в вашем коде, такие как использование недопустимого индекса массива или разыменование неинициализированного указателя или указателя на освобожденную память.

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

Как и предполагали другие, перезапуск valgrind после компиляции с отладочной информацией (-g) будет хорошим следующим шагом.

0 голосов
/ 03 мая 2019

Если вы получаете ошибку ниже: - «Недопустимое чтение размера 4»

Вы освобождаете память раньше, а затем переходите к следующему аргументу? Я также получаю сообщение об ошибке, потому что в связанном списке я сначала освобождаю память, а затем перехожу к следующему элементу. Ниже приведен фрагмент кода, где я получаю сообщение об ошибке -

void free_memory(Llist **head_ref)
{
    Llist *current=NULL;

    current=*head_ref;
    while(*head_ref != NULL)
    {
        current=*head_ref;
        free(current);
        current=NULL;
        (*head_ref)=(*head_ref)->next;
    }
}

После внесенных изменений мой фрагмент кода -

void free_memory(Llist **head_ref)
{
    Llist *current=NULL;
    current=*head_ref;
    while(*head_ref != NULL)
    {
        current=*head_ref;
        (*head_ref)=(*head_ref)->next;
        free(current);
        current=NULL;
     }
 }
...