Valgrind legítimo "posiblemente perdido" bytes ejemplo

Question

vi que valgrind clasifica las pérdidas de memoria en:

• definitivamente perdida
• indirectamente perdido
• posiblemente perdido
• todavía alcanzable
• suprimidos

Acabo de arreglar una fuga donde la "posible perdida" era el problema principal.

El documentation says: "posiblemente perdieron significa que su programa está perdiendo memoria, a menos que usted está haciendo cosas raras con los punteros que podrían causar que señalen en el medio de un bloque asignado; ver el manual de usuario para una posible causas "

¿Puedo saber por favor un ejemplo de" hacer cosas inusuales con punteros que podrían causar que apuntan hacia el centro de un bloque asignado "?

Me refiero a un ejemplo en el que "posiblemente perdido" puede ser ignorado aunque valgrind lo notifique. Un ejemplo en el que el uso de punteros hace valgrind se quejan, pero al mismo tiempo el uso de los punteros de esa manera es de alguna manera legítima

Gracias

Answer 1

Algunos ejemplos de lo que la documentación son diferentes bibliotecas que tienen sus propios asignadores y para los que no se devuelve la memoria directamente, el puntero devuelto por el asignador de sistema operativo subyacente (malloc/sbrk), pero un puntero después de un desplazamiento. Considere por ejemplo, un asignador que obtuvo algo de memoria extra y metainformación almacenada (tal vez escriba información para un recolector de basura ...). El proceso de asignación y desasignación sería similar a:

void* allocate(size_t size) { 
    metainfo_t *m = (metainfo_t*) malloc(size + sizeof(metainfo)); 
    m->data = some_value; 
    return (void*)(m+1);   // [1] 
} 
void deallocate(void* p) { 
    metainfo_t *m = ((metainfo_t*)p) - 1; 
    // use data 
} 
void * memory = allocate(10); 

Cuando valgrind es el seguimiento de la memoria, que recuerda el puntero original que fue devuelto por malloc, y que el puntero no se almacena en el programa. Pero eso no significa que la memoria se haya filtrado, solo significa que el puntero no está directamente disponible en el programa. En particular, memory aún conserva el puntero devuelto y se puede invocar deallocate para liberarlo, pero valgrind no ve el puntero original devuelto en la ubicación (char*)memory - sizeof(metadata_t) en ninguna parte del programa y advierte.

Answer 2

char *p = malloc(100); 
if (p != 0) 
{ 
    p += 50; 
    /* at this point, no pointer points to the start of the allocated memory */ 
    /* however, it is still accessible */ 
    for (int i = -50; i != 50; i++) 
     p[i] = 1; 
    free (p - 50); 
} 

Answer 3

char *p = malloc(100); 
if (p != 0) 
{ 
    p += 50; 
    /* at this point, no pointer points to the start of the allocated memory */ 
    /* however, it is still accessible */ 
    for (int i = -50; i != 50; i++) 
     p[i] = 1; 
    free (p - 50); 
} 

Dado que se ve muy interesante, ejecuté el código y lo valoré. El resultado es el siguiente.

yjaeyong@carbon:~$ valgrind test 
==14735== Memcheck, a memory error detector 
==14735== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. 
==14735== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info 
==14735== Command: test 
==14735== 
==14735== 
==14735== HEAP SUMMARY: 
==14735==  in use at exit: 0 bytes in 0 blocks 
==14735== total heap usage: 32 allocs, 32 frees, 2,017 bytes allocated 
==14735== 
==14735== All heap blocks were freed -- no leaks are possible 
==14735== 
==14735== For counts of detected and suppressed errors, rerun with: -v 
==14735== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 6) 

Dice que no hay fugas posibles. ¿Me estoy perdiendo algo?