内存没有释放，但仍可达，出现泄漏。 [英] Memory not freed but still reachable, is it leaking?

问题描述

通过与Valgrind的检查，我看到的内存块5终止我的程序后不会释放，但他们仍然到达。我是否需要被它困扰？

和它是如何发生的？

 站务@凝胶剂：〜/ $沙盘的valgrind ./a.out
== == 2430 MEMCHECK，内存错误检测
== == 2430版权所有（C）2002-2010，和GNU GPL的，Julian Seward写等。
== == 2430 Valgrind的使用，3.6.1和LibVEX;与-h版权信息重新运行
== == 2430命令：./a.out
== == 2430
你好，世界！
线程1返回1
线程2返回10
Thread3返回10
== == 2430
== == 2430 HEAP摘要：
== == 2430使用在出口处：在5块1,590个字节
== == 2430总堆的使用情况：14 allocs，9的FreeS，2,442字节分配
== == 2430
== == 2430泄漏摘要：
== == 2430肯定丢失：0字节0块
== == 2430失去了间接：0字节0块
== == 2430可能丢失：0字节0块
== == 2430到达尚：在5块1,590个字节
== == 2430燮pressed：0字节0块
== == 2430与重新运行--leak检查=全看到内存泄露的细节
== == 2430
== == 2430对于检测燮pressed错误计数，重新运行：-v
== == 2430错误摘要：从0 0上下文错误（SUP pressed：4 4）
 

---

下面是我的code，我能做些什么，以释放那些5块，如果我打算？

 的#include＆LT; pthreads.h中＆GT;
＃包括LT＆;＆stdio.h中GT;
＃包括LT＆;＆stdlib.h中GT;pthread_mutex_t互斥锁= PTHREAD_MUTEX_INITIALIZER;无效* MyFunction的（无效* PTR）
{
    静态INT n_call = 0;
    为int * RETVAL =的malloc（sizeof的（INT））;    调用pthread_mutex_lock（安培;互斥锁）;
    n_call ++;
    * RETVAL = n_call;
    调用pthread_mutex_unlock（安培;互斥锁）;    如果（n_call 2）
    {
        字符*味精;
        味精=（字符*）PTR;
        的printf（％S \\ n，味精）;        返回RETVAL;
    }
    其他
    {
        * RETVAL = 10;
        了pthread_exit（RETVAL）;
    }
}INT主（INT ARGC，CHAR *的argv []）
{
    的pthread_t T1，T2，T3;    字符*味精=世界，你好！
    在pthread_create（安培; T1，NULL，MyFunction的（无效*）味精）;
    在pthread_create（安培; T2，NULL，MyFunction的（无效*）味精）;
    在pthread_create（安培; T3，NULL，MyFunction的（无效*）味精）;    INT ** S1 =的malloc（sizeof的为（int *））;
    INT ** S2 =的malloc（sizeof的为（int *））;
    INT ** S3 =的malloc（sizeof的为（int *））;    在pthread_join（T1，（空隙**）S1）;
    在pthread_join（T2，（空隙**）S2）;
    在pthread_join（T3，（空隙**）S3）;    的printf（线程1返回％d个\\ N，** S1）;
    的printf（线程2返回％d个\\ N，** S2）;
    的printf（Thread3返回％d个\\ N，** S3）;    免费（* S1）;
    免费（* S2）;
    免费（* S3）;    免费（S1）;
    免费（S2）;
    免费（S3）;    返回0;
}
 

解决方案

没有它不是一个内存泄漏。结果
这意味着你的计划仍具有参考内存稍后获释。

不同的消息之间

Valgrind的常见问题解答 区分如下：

  

使用MEMCHECK的内存泄漏检测器，什么是之间肯定迷失，间接丢失，可能失去，依然可达和SUP pressed？

的区别
  
  

的细节是在用户手册的MEMCHECK部分。

  
  

在短：

  
  

  

• 肯定失去表示你的程序正在泄漏内存 - 修复这些泄漏

！
  

• 间接失去意味着你的程序在基于指针的结构泄漏内存。 （例如，如果一个二进制树的根节点肯定丢失，所有的孩子将是间接丢失。）如果你修复肯定失去泄漏，在间接失去泄漏应该走了。


  

• 可能失去表示你的程序正在泄漏内存，除非你做有趣的事情指针。这是合理的有时。结果
    使用 - 展示 - 可能丢=没有如果你不希望看到这些报道


  

• 依旧可达意味着你的程序可能是好的 - 它不释放一些内存它可能有。这是很常见的，通常合理的。结果
    不要使用 - 展示 - 可达= YES 如果你不希望看到这些报道


  

• 燮pressed 意味着泄漏的错误已燮pressed。有默认SUP pression文件的一些燮pressions。您可以忽略燮pressed错误。


  

By checking with valgrind, I see that 5 blocks of memory were not freed after terminating my program, but they are still reachable. Do I need to be bothered by it?

And how it happens?

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)

---

Below is my code, what can I do to free those 5 blocks if I intend to?

#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("%s\n", 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 %d\n", **s1);
    printf("Thread2 returns %d\n", **s2);
    printf("Thread3 returns %d\n", **s3);

    free(*s1);
    free(*s2);
    free(*s3);

    free(s1);
    free(s2);
    free(s3);

    return 0;
}

解决方案

No it is not a memory leak.
It means your program still has reference to memory that will freed later.

Valgrind FAQ differentiates between different messages as follows:

With Memcheck's memory leak detector, what's the difference between "definitely lost", "indirectly lost", "possibly lost", "still reachable", and "suppressed"?

The details are in the Memcheck section of the user manual.

In short:

• definitely lost means your program is leaking memory -- fix those leaks!

• indirectly lost means your program is leaking memory in a pointer-based structure. (E.g. if the root node of a binary tree is "definitely lost", all the children will be "indirectly lost".) If you fix the definitely lost leaks, the indirectly lost leaks should go away.

• possibly lost means your program is leaking memory, unless you're doing funny things with pointers. This is sometimes reasonable.
  Use --show-possibly-lost=no if you don't want to see these reports.

• still reachable means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable.
  Don't use --show-reachable=yes if you don't want to see these reports.

• suppressed means that a leak error has been suppressed. There are some suppressions in the default suppression files. You can ignore suppressed errors.

这篇关于内存没有释放，但仍可达，出现泄漏。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！