c Aufräumen ungenutzte Threads

Question

Ich habe eine Reihe von Threads gemacht, aber ich benutze nicht alle von ihnen. es stellt sich heraus, dass es ein Speicherleck ist. Gibt es irgendeine Funktion, die ich verwenden könnte, um den Speicher freizugeben?

void func(args...) 
{ 
. 
. 
. 
pthread_t threads[10] 

int i; 
for(i = 0; i < 8; i++) 
{ 
    /* create 8 threads */ 
} 
for(i = 0; i < 8; i++) 
{ 
    /* join 8 threads */ 
} 
. 
. 
. 
return; 
} 

Der Code, den ich für das Experiment verwendet habe, ist hier. Ich benutze mehr Threads als ich möchte. Wenn ich die 10 weiteren Threads nicht hinzufüge, wird es überhaupt kein Leck geben. es dauert einige Textdateien als Argument Kompilieren und Ausführen mit

gcc -g -Wall -pthread test.c valgrind --tool = memcheck --leak-check = full --show-erreichbar = yes ./a .out * .txt

Hier ist, was Valgrind druckt, wenn ich das Programm ausführen. Das Speicherleck stammt von der Funktion Ich erstelle die unbenutzten Threads. manchmal druckt es diese Nachricht, manchmal nicht.

==4737== 
==4737== HEAP SUMMARY: 
==4737==  in use at exit: 1,590 bytes in 5 blocks 
==4737== total heap usage: 12 allocs, 7 frees, 3,494 bytes allocated 
==4737== 
==4737== 36 bytes in 1 blocks are still reachable in loss record 1 of 5 
==4737== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) 
==4737== by 0x40085BF: _dl_map_object (dl-load.c:162) 
==4737== by 0x4012B79: dl_open_worker (dl-open.c:226) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x40133A9: _dl_open (dl-open.c:569) 
==4737== by 0x516AF6F: do_dlopen (dl-libc.c:86) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x516B029: __libc_dlopen_mode (dl-libc.c:47) 
==4737== by 0x4E3F75B: pthread_cancel_init (unwind-forcedunwind.c:53) 
==4737== by 0x4E3F91B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==4737== by 0x4E3D9DF: __pthread_unwind (unwind.c:130) 
==4737== by 0x4E380A4: pthread_exit (pthreadP.h:265) 
==4737== 
==4737== 36 bytes in 1 blocks are still reachable in loss record 2 of 5 
==4737== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) 
==4737== by 0x400B43C: _dl_new_object (dl-object.c:164) 
==4737== by 0x4006575: _dl_map_object_from_fd (dl-load.c:967) 
==4737== by 0x400831E: _dl_map_object (dl-load.c:2260) 
==4737== by 0x4012B79: dl_open_worker (dl-open.c:226) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x40133A9: _dl_open (dl-open.c:569) 
==4737== by 0x516AF6F: do_dlopen (dl-libc.c:86) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x516B029: __libc_dlopen_mode (dl-libc.c:47) 
==4737== by 0x4E3F75B: pthread_cancel_init (unwind-forcedunwind.c:53) 
==4737== by 0x4E3F91B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==4737== 
==4737== 56 bytes in 1 blocks are still reachable in loss record 3 of 5 
==4737== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) 
==4737== by 0x400D187: _dl_map_object_deps (dl-deps.c:505) 
==4737== by 0x4012BD6: dl_open_worker (dl-open.c:263) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x40133A9: _dl_open (dl-open.c:569) 
==4737== by 0x516AF6F: do_dlopen (dl-libc.c:86) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x516B029: __libc_dlopen_mode (dl-libc.c:47) 
==4737== by 0x4E3F75B: pthread_cancel_init (unwind-forcedunwind.c:53) 
==4737== by 0x4E3F91B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==4737== by 0x4E3D9DF: __pthread_unwind (unwind.c:130) 
==4737== by 0x4E380A4: pthread_exit (pthreadP.h:265) 
==4737== 
==4737== 288 bytes in 1 blocks are still reachable in loss record 4 of 5 
==4737== at 0x4C279F2: calloc (vg_replace_malloc.c:467) 
==4737== by 0x4010359: _dl_check_map_versions (dl-version.c:300) 
==4737== by 0x4012EF0: dl_open_worker (dl-open.c:269) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x40133A9: _dl_open (dl-open.c:569) 
==4737== by 0x516AF6F: do_dlopen (dl-libc.c:86) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x516B029: __libc_dlopen_mode (dl-libc.c:47) 
==4737== by 0x4E3F75B: pthread_cancel_init (unwind-forcedunwind.c:53) 
==4737== by 0x4E3F91B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==4737== by 0x4E3D9DF: __pthread_unwind (unwind.c:130) 
==4737== by 0x4E380A4: pthread_exit (pthreadP.h:265) 
==4737== 
==4737== 1,174 bytes in 1 blocks are still reachable in loss record 5 of 5 
==4737== at 0x4C279F2: calloc (vg_replace_malloc.c:467) 
==4737== by 0x400B1CD: _dl_new_object (dl-object.c:77) 
==4737== by 0x4006575: _dl_map_object_from_fd (dl-load.c:967) 
==4737== by 0x400831E: _dl_map_object (dl-load.c:2260) 
==4737== by 0x4012B79: dl_open_worker (dl-open.c:226) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x40133A9: _dl_open (dl-open.c:569) 
==4737== by 0x516AF6F: do_dlopen (dl-libc.c:86) 
==4737== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==4737== by 0x516B029: __libc_dlopen_mode (dl-libc.c:47) 
==4737== by 0x4E3F75B: pthread_cancel_init (unwind-forcedunwind.c:53) 
==4737== by 0x4E3F91B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==4737== 
==4737== LEAK SUMMARY: 
==4737== definitely lost: 0 bytes in 0 blocks 
==4737== indirectly lost: 0 bytes in 0 blocks 
==4737==  possibly lost: 0 bytes in 0 blocks 
==4737== still reachable: 1,590 bytes in 5 blocks 
==4737==   suppressed: 0 bytes in 0 blocks 
==4737== 
==4737== For counts of detected and suppressed errors, rerun with: -v 
==4737== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) 

Answer 1

Das "Problem" die Verwendung von pthread_exit. This question gibt einige Details, speziell:

Mehrere glibc Funktionen Speicher mit malloc() das erste Mal, wenn sie genannt werden, weisen die sie für den Rest des Prozesses Lebensdauer zugeordnet halten. Glibc kümmert sich nicht darum, diese Speicherkapazität beim Prozessausgang freizugeben, da es weiß, dass der Prozess sowieso abgebrochen wird - es wäre nur eine Verschwendung von CPU-Zyklen.

Also dieses Speicherleck ist in Ordnung.

jedoch tatsächlich die valgrind Nachrichten loszuwerden, können Sie return NULL; anstelle von pthread_exit(NULL); in der letzten Zeile von countLines verwenden, da Sie gerade von der Startroutine zurück.