valgrind errores de pérdida de memoria cuando se utiliza pthread_create

Estoy escribiendo un progtwig usando la biblioteca pthread. Cuando ejecuto mi progtwig con el comando valgrind –leak-check = full, obtengo la siguiente descripción de errores:

==11784== ==11784== **HEAP SUMMARY:** ==11784== in use at exit: 4,952 bytes in 18 blocks ==11784== total heap usage: 1,059 allocs, 1,041 frees, 51,864 bytes allocated ==11784== ==11784== **288 bytes** in 1 blocks are possibly lost in loss record 2 of 3 ==11784== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==11784== by 0x4010D2E: _dl_allocate_tls (dl-tls.c:300) ==11784== by 0x55DC218: **pthread_create**@@GLIBC_2.2.5 (allocatestack.c:570) ==11784== by 0x401BC0: initdevice(char*) (in /a/fr-01/vol/home/stud/lim/workspace /Ex3/l) ==11784== by 0x406D05: main (in /a/fr-01/vol/home/stud/lim/workspace/Ex3/l) ==11784== ==11784== **4,608 bytes** in 16 blocks are possibly lost in loss record 3 of 3 ==11784== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==11784== by 0x4010D2E: _dl_allocate_tls (dl-tls.c:300) ==11784== by 0x55DC218: **pthread_create**@@GLIBC_2.2.5 (allocatestack.c:570) ==11784== by 0x40268F: write2device(char*, int) (in /a/fr-01/vol/home/stud/lim/workspace/Ex3/l) ==11784== by 0x406D7B: main (in /a/fr-01/vol/home/stud/lim/workspace/Ex3/l) ==11784== ==11784== **LEAK SUMMARY:** ==11784== definitely lost: 0 bytes in 0 blocks ==11784== indirectly lost: 0 bytes in 0 blocks ==11784== possibly lost: 4,896 bytes in 17 blocks ==11784== still reachable: 56 bytes in 1 blocks ==11784== suppressed: 0 bytes in 0 blocks ==11784== Reachable blocks (those to which a pointer was found) are not shown. ==11784== To see them, rerun with: --leak-check=full --show-reachable=yes ==11784== ==11784== For counts of detected and suppressed errors, rerun with: -v ==11784== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4) 

Cada vez que llamo a pthread_create, con una función determinada, llamo a la función pthread_exit al final de la función. Entonces, después de verificar que este no es el problema, ¿cuál podría ser el problema?

Los recursos de un subproceso no se liberan inmediatamente al finalizar, a menos que el subproceso se haya creado con el atributo de detach state de PTHREAD_CREATE_DETACHED establecido en PTHREAD_CREATE_DETACHED , o si pthread_detach se llama para su pthread_t .

Un subproceso indefinido permanecerá en estado terminado hasta que su identificador se pase a pthread_join o pthread_detach .

Para resumir, tienes tres opciones:

  1. crea tu hilo con el conjunto de atributos separados (atributo PTHREAD_CREATE_DETACHED)
  2. Separe su hilo después de la creación (llamando a pthread_detach ), o
  3. Únase con los hilos terminados para reciclarlos (llamando a pthread_join ).

Hth.

cuando no se trabaja con hilos que se pueden unir, el hilo que sale necesita llamar a pthread_detach(pthread_self()) para liberar todos sus recursos.

O bien, puede hacer que el subproceso se desconecte para evitar la pérdida de memoria si el subproceso no se debe unir (o simplemente caduca por sí mismo)

Para crear explícitamente un hilo como separable o unible, se usa el argumento attr en la rutina pthread_create (). El proceso típico de 4 pasos es:

  • Declarar una variable de atributo pthread del tipo de datos pthread_attr_t
  • Inicialice la variable de atributo con pthread_attr_init ()
  • Establezca el estado separado de atributo con pthread_attr_setdetachstate ()
  • Cuando haya terminado, recursos de biblioteca gratuitos utilizados por el atributo con pthread_attr_destroy ()

Además de las respuestas correctas que le dieron otros usuarios, le sugiero que lea esto:

Rastreando una fuga de memoria en la aplicación C multiproceso

Tenga en cuenta que el comportamiento predeterminado de pthread_create es “unible” NO DISTINTO. Por lo tanto, algunos recursos del sistema operativo aún se mantendrían en el proceso una vez finalizado pthread, lo que daría lugar a subprocesos zombie y llevaría a un mayor uso de memoria VIRTUAL / residente.

Las cuatro soluciones @sehe mencionadas solucionarían este problema.

Sin embargo, si el hilo es antiguo, podría no ser realmente necesario. por ejemplo, si el pthread vive durante toda la vida del proceso.