This came up while investigating http://code.google.com/p/chromium/issues/detail?id=64930 and after reading http://stackoverflow.com/questions/815439/how-to-free-dynamic-allocated-variable-by-sigterm Reproducer (Lucid x64): ===test.cpp=== #include <stdio.h> #include <string> std::string *mystr; int main() { mystr = new std::string; *mystr = "ASDASD"; char tmp[100]; scanf("%s", tmp); delete mystr; } ============== $ g++ test.cpp && valgrind --leak-check=full ./a.out ... <it waits on scanf> If you type something and hit <Enter>, no leaks are reported (correct behaviour). However, if you hit Ctrl+C (or send "kill -n 15 <pid>"), it reports the following: ==5582== HEAP SUMMARY: ==5582== in use at exit: 39 bytes in 2 blocks ==5582== total heap usage: 2 allocs, 0 frees, 39 bytes allocated ==5582== ==5582== 31 bytes in 1 blocks are possibly lost in loss record 2 of 2 ==5582== at 0x4C2B006: operator new(unsigned long) (vg_replace_malloc.c:261) ==5582== by 0x4ED8D98: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:89) ==5582== by 0x4EDA9E9: std::string::_M_mutate(unsigned long, unsigned long, unsigned long) (basic_string.tcc:457) ==5582== by 0x4EDAB7B: std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) (basic_string.tcc:662) ==5582== by 0x400875: main (test4.cpp:8) ==5582== ==5582== LEAK SUMMARY: ==5582== definitely lost: 0 bytes in 0 blocks ==5582== indirectly lost: 0 bytes in 0 blocks ==5582== possibly lost: 31 bytes in 1 blocks ==5582== still reachable: 8 bytes in 1 blocks ==5582== suppressed: 0 bytes in 0 blocks So, Memcheck performs leak-checking after receiving SIGTERM. To my mind, it shouldn't. (at least if the client application doesn't define its custom signal handler) What do you think? It looks like running large multi-process tests like Chromium could be much faster if Memcheck skipped the leak-checking phase after receiving a signal.
The report may change slightly: -------------------- void* thread_func(void *) { std::string str = "Valgrind"; str += " rocks\n"; printf("Entering!\n"); usleep(100000); // Make sure the thread is killed printf("Finished!\n"); return 0; } -------------------- results in: ==20839== 153 bytes in 1 blocks are possibly lost in loss record 1 of 2 ==20839== at 0x4C2B2A6: operator new(unsigned long) (vg_replace_malloc.c:261) ==20839== by 0x50F6D98: std::string::_Rep::_S_create(...) (new_allocator.h:89) ==20839== by 0x50F776A: std::string::_Rep::_M_clone(...) (basic_string.tcc:607) ==20839== by 0x50F829B: std::string::reserve(unsigned long) (basic_string.tcc:488) ==20839== by 0x50F84E7: std::string::append(...) (basic_string.tcc:309) ==20839== by 0x400BE8: thread_func(void*) (repstr.cpp:11) ==20839== by 0x4E389C9: start_thread (pthread_create.c:300) ==20839== by 0x58E370C: clone (clone.S:112)
Terribly sorry: the last comment should have been added to bug 280271
Related: Why does Valgrind perform leak-checking when it gets a SIGSEGV? -------------------------- #include <malloc.h> int main(void) { char * mystr = (char*)malloc(16); mystr = (char*)0; /* Someone has corrupted the pointer */ *mystr = 0; free(mystr); } -------------------------- ==22700== Invalid write of size 1 ==22700== at 0x400586: main (read_null.c:6) ==22700== Address 0x0 is not stack'd, malloc'd or (recently) free'd ... ==22700== Process terminating with default action of signal 11 (SIGSEGV) ==22700== Access not within mapped region at address 0x0 ==22700== at 0x400586: main (read_null.c:6) ==22700== ... ==22700== HEAP SUMMARY: ==22700== ... ==22700== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==22700== at 0x4C2A05F: malloc (vg_replace_malloc.c:236) ==22700== by 0x400575: main (read_null.c:4) ==22700== ==22700== LEAK SUMMARY: ==22700== definitely lost: 16 bytes in 1 blocks
Re: SIGTERM I've heard some Linux programs always shut down their children using SIGTERM? In this case Memcheck should continue doing leak-checking on SIGTERM; but (I think) not on SIGSEGV
https://stackoverflow.com/questions/53525458/valgrind-suppress-memory-memory-leak-reporting-iff-program-crashed