Valgrind: ¿puede posiblemente perdido ser tratado como definitivamente perdido?


¿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 se han movido a lo largo, o podría ser totalmente sin relación. Memcheck considera que tal bloqueo es "dudoso", porque no está claro si un puntero a ella todavía existe.

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

 30
Author: lesmana, 2010-08-21

1 answers

Sí, recomiendo a tratar posiblemente perdido tan grave como perdido definitivamente. En otras palabras, arregle su código hasta que no haya pérdidas en absoluto.

Posiblemente perdido puede ocurrir cuando se recorre un array usando el mismo puntero que lo sostiene. Usted sabe que puede restablecer el puntero restando el índice. Pero valgrind no puede decir si es un error de programación o si estás siendo inteligente haciendo esto deliberadamente. Es por eso que advierte usted.

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 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 la falla de segmento, entonces Valgrind no reportará ninguna pérdida de memoria en absoluto. Sin segfault, el puntero volverá al principio de la matriz y la memoria será freed correctamente.

Este es un ejemplo trivial. En código suficientemente complicado ya no es obvio que el puntero puede y volverá al principio del bloque de memoria. Cambios en otros parte del código puede hacer que posiblemente perdido sea un definitivamente perdido. Es por eso que usted debe preocuparse por posiblemente perdido.

 54
Author: lesmana,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-01-22 13:45:15