Память не освобождена, но все еще доступна, она протекает?
проверяя с valgrind, я вижу, что 5 блоков памяти не были освобождены после завершения моей программы, но они все еще доступны. Мне нужно беспокоиться об этом?
и как это происходит?
zhanwu@gelata:~/sandbox$ valgrind ./a.out
==2430== Memcheck, a memory error detector
==2430== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2430== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2430== Command: ./a.out
==2430==
Hello world!
Thread1 returns 1
Thread2 returns 10
Thread3 returns 10
==2430==
==2430== HEAP SUMMARY:
==2430== in use at exit: 1,590 bytes in 5 blocks
==2430== total heap usage: 14 allocs, 9 frees, 2,442 bytes allocated
==2430==
==2430== LEAK SUMMARY:
==2430== definitely lost: 0 bytes in 0 blocks
==2430== indirectly lost: 0 bytes in 0 blocks
==2430== possibly lost: 0 bytes in 0 blocks
==2430== still reachable: 1,590 bytes in 5 blocks
==2430== suppressed: 0 bytes in 0 blocks
==2430== Rerun with --leak-check=full to see details of leaked memory
==2430==
==2430== For counts of detected and suppressed errors, rerun with: -v
==2430== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
ниже мой код, что я могу сделать, чтобы освободить этих 5 блоков, если я намерен?
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
void* myfunction(void *ptr)
{
static int n_call = 0;
int *retval = malloc(sizeof(int));
pthread_mutex_lock( &mutex1 );
n_call++;
*retval = n_call;
pthread_mutex_unlock( &mutex1 );
if(n_call < 2)
{
char *msg;
msg = (char *)ptr;
printf("%sn", msg);
return retval;
}
else
{
*retval = 10;
pthread_exit(retval);
}
}
int main(int argc, char *argv[])
{
pthread_t t1, t2, t3;
char *msg = "Hello world!";
pthread_create(&t1, NULL, myfunction, (void *)msg);
pthread_create(&t2, NULL, myfunction, (void *)msg);
pthread_create(&t3, NULL, myfunction, (void *)msg);
int **s1 = malloc(sizeof(int*));
int **s2 = malloc(sizeof(int*));
int **s3 = malloc(sizeof(int*));
pthread_join(t1, (void **)s1);
pthread_join(t2, (void **)s2);
pthread_join(t3, (void **)s3);
printf("Thread1 returns %dn", **s1);
printf("Thread2 returns %dn", **s2);
printf("Thread3 returns %dn", **s3);
free(*s1);
free(*s2);
free(*s3);
free(s1);
free(s2);
free(s3);
return 0;
}
2 ответов
нет, это не утечка памяти.
Это означает, что ваша программа все еще имеет ссылку на память, которая будет освобождена позже.
Valgrind FAQ различает различные сообщения следующим образом:
с детектором утечки памяти Memcheck, в чем разница между" определенно потерянным"," косвенно потерянным"," возможно потерянным"," все еще достижимым "и"подавленным"?
подробности находятся в разделе Memcheck руководство пользователя.
короче:
наверняка потерял означает, что ваша программа утечка памяти-исправить эти утечки!
косвенно потерял означает, что ваша программа утечка памяти в структуре на основе указателя. (Например. если корневой узел двоичного дерева "определенно потерян", все дочерние элементы будут"косвенно потеряны".) Если вы исправите
definitely lost
утечек,indirectly lost
утечки должен идти прочь.возможно, потерял означает, что ваша программа протекает память, если вы не делаете смешные вещи с указателями. Иногда это разумно.
Использовать--show-possibly-lost=no
Если вы не хотите видеть эти сообщения.все еще достижимый означает, что ваша программа, вероятно, в порядке - она не освободила память, которую могла бы иметь. Это довольно распространено и часто разумно.
Не используйте--show-reachable=yes
Если вы не хотите видеть эти сообщить.подавленные означает, что ошибка утечки была подавлена. Есть некоторые подавления в файлах подавления по умолчанию. Подавленные ошибки можно игнорировать.
Это зависит.
Это может быть настоящая утечка, а может и нет. Но в любом случае ты должен это исправить.
Если вы выделяете буфер и держите его до конца программы, технически это утечка, но это не имеет значения - вы выделяете только один буфер, и он в основном постоянный.
с другой стороны, возможно, вы выделяем буфер таким образом, что это делается только один раз в тестовом коде, но позже с реальным кодексом может сделать выделили не один раз-значит, у вас утечка.
поэтому лучше всего исправить их все.