seguir - Valgrind: ¿la pérdida puede ser tratada como definitivamente perdida?

no puedo seguir hashtags en instagram

Question

¿Puedo tratar la salida de un memcheck de Valgrind, "posiblemente perdido" como "definitivamente perdido"?

Posiblemente perdido, o "dudoso": se encuentra un puntero al interior del bloque. El puntero podría haber apuntado originalmente al inicio y haber sido movido a lo largo, o podría no tener ninguna relación. Memcheck considera tal bloque como "dudoso", porque no está claro si todavía existe un puntero hacia él.

Definitivamente perdido o "filtrado": el peor resultado es que no se puede encontrar un puntero al bloque. El bloque se clasifica como "filtrado", porque el programador no podría haberlo liberado al salir del programa, ya que no existe ningún puntero hacia él. Este es probablemente un síntoma de haber perdido el puntero en algún punto anterior del programa.

Answer 1

Sí, recomiendo tratar la pérdida posiblemente tan grave como definitivamente perdida . En otras palabras, corrija su código hasta que no haya pérdidas en absoluto.

Posiblemente se puede perder cuando atraviesa una matriz utilizando el mismo puntero que la contiene. Sabe que puede restablecer el puntero restando el índice. Pero valgrind no puede saber si se trata de un error de programación o si está siendo inteligente haciendo esto deliberadamente. Por eso te lo advierte.

Ejemplo

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv) {
char* s = "string";
// this will allocate a new array
char* p = strdup(s);
// move the pointer into the array
// we know we can reset the pointer by subtracting
// but for valgrind the array is now lost
p += 1;
// deliberately trigger a segfault to crash the program
*s = ''S'';
// reset the pointer to the beginning of the array
p -= 1;
// properly free the memory for the array
free(p);
return 0;
}

Compilar

$ gcc -ggdb foo.c -o foo

Informe de valgrind

$ valgrind ./foo
...
==3415== Command: ./foo
==3415==
==3415==
==3415== Process terminating with default action of signal 11 (SIGSEGV)
==3415== Bad permissions for mapped region at address 0x80484E0
==3415== at 0x804840E: main (foo.c:14)
==3415==
==3415== HEAP SUMMARY:
==3415== in use at exit: 7 bytes in 1 blocks
==3415== total heap usage: 1 allocs, 0 frees, 7 bytes allocated
==3415==
==3415== LEAK SUMMARY:
==3415== definitely lost: 0 bytes in 0 blocks
==3415== indirectly lost: 0 bytes in 0 blocks
==3415== possibly lost: 7 bytes in 1 blocks
==3415== still reachable: 0 bytes in 0 blocks
==3415== suppressed: 0 bytes in 0 blocks
...

Si elimina la línea que causa el fallo de seguridad, Valgrind no informará de ninguna pérdida de memoria. Sin segfault, el puntero volverá al principio de la matriz y la memoria quedará free d correctamente.

Este es un ejemplo trivial. En un código suficientemente complicado, ya no es obvio que el puntero pueda regresar al principio del bloque de memoria y lo hará. Los cambios en otra parte del código pueden causar la pérdida de una pérdida definitiva . Es por eso que debes preocuparte por la posible pérdida .