Memoria no liberada pero aún alcanzable, ¿está goteando?

memory pthreads

Question

Al verificar con valgrind, veo que 5 bloques de memoria no se liberaron después de finalizar mi programa, pero todavía son alcanzables. ¿Debo ser molestado por eso?

¿Y cómo sucede?

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)

Debajo está mi código, ¿qué puedo hacer para liberar esos 5 bloques si tengo la intención de hacerlo?

#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;
}

Answer 1

Depende.

Puede ser una fuga real, y puede que no. Pero de cualquier forma debes arreglarlo.

Si asigna un buffer y lo mantiene hasta el final del programa, técnicamente es una filtración, pero no importa; solo asigna un buffer, y es básicamente permanente.

Por otro lado, quizás esté asignando un búfer de forma tal que se hace una sola vez en su código de prueba, pero más tarde con el código real podría asignarse más de una vez, entonces tiene una fuga.

Entonces, es mejor arreglarlos a todos.

Answer 2

No, no es una pérdida de memoria.
Significa que su programa todavía tiene referencia a la memoria que se liberará más tarde.

Valgrind FAQ diferencia entre diferentes mensajes de la siguiente manera:

Con el detector de fugas de memoria de Memcheck, ¿cuál es la diferencia entre "definitivamente perdido", "perdido indirectamente", "posiblemente perdido", "todavía accesible" y "suprimido"?

Los detalles se encuentran en la sección Memcheck del manual del usuario.

En breve:

• definitivamente perdido significa que tu programa está perdiendo memoria. ¡Arregla esas fugas!

• Perdido indirectamente significa que su programa está perdiendo memoria en una estructura basada en punteros. (Por ejemplo, si el nodo raíz de un árbol binario está "definitivamente perdido", todos los niños se perderán "indirectamente"). Si arreglas las pérdidas definitely lost , las pérdidas indirectly lost deberían desaparecer.

• posiblemente perdido significa que su programa está perdiendo memoria, a menos que esté haciendo cosas divertidas con punteros. Esto a veces es razonable.
  Use --show-possibly-lost=no si no desea ver estos informes.

• aún alcanzable significa que su programa probablemente esté bien; no liberó parte de la memoria que podría tener. Esto es bastante común y a menudo razonable.
  No use --show-reachable=yes si no desea ver estos informes.

• suprimido significa que se ha suprimido un error de fuga. Hay algunas supresiones en los archivos de supresión predeterminados. Puede ignorar los errores suprimidos.