Reputation: 866
It is more of a general query, what would be the behaviour of valgrind memcheck if some of the threads spawned do not gracefully terminate. I mean the case when the threads are detached and do not share any memory with parent process/ thread.
I dont have any code snippet or valgrind output, as it is a question just out of curiosity
Upvotes: 1
Views: 1113
Reputation: 41017
For this piece of code:
while (1) {
pthread_t thread;
struct sockaddr_in client;
socklen_t len = sizeof(client);
int newsock = accept(sock, (struct sockaddr *)&client, &len);
if (newsock == -1) {
perror("accept");
} else {
if (pthread_create(&thread, NULL, handle, &newsock) != 0) {
perror("pthread_create");
} else {
pthread_detach(thread);
}
}
if (count == 5) break;
}
close(sock);
exit(EXIT_SUCCESS);
Where a thread is still waiting for accept()
, it shows a possibly lost:
david@debian:~$ valgrind ./server
==24561== Memcheck, a memory error detector
==24561== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==24561== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==24561== Command: ./server
==24561==
0
1
2
3
4
5
==24561==
==24561== HEAP SUMMARY:
==24561== in use at exit: 272 bytes in 1 blocks
==24561== total heap usage: 3 allocs, 2 frees, 1,408 bytes allocated
==24561==
==24561== LEAK SUMMARY:
==24561== definitely lost: 0 bytes in 0 blocks
==24561== indirectly lost: 0 bytes in 0 blocks
==24561== possibly lost: 272 bytes in 1 blocks
==24561== still reachable: 0 bytes in 0 blocks
==24561== suppressed: 0 bytes in 0 blocks
==24561== Rerun with --leak-check=full to see details of leaked memory
==24561==
==24561== For counts of detected and suppressed errors, rerun with: -v
==24561== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
Upvotes: 1