Bug 265371

Summary: Memcheck performs leak-checking even if killed by SIGTERM
Product: [Developer tools] valgrind Reporter: Timur Iskhodzhanov <timurrrr>
Component: memcheckAssignee: Julian Seward <jseward>
Status: REPORTED ---    
Severity: normal CC: laurynas.biveinis
Priority: NOR    
Version First Reported In: 3.7 SVN   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Timur Iskhodzhanov 2011-02-04 09:00:19 UTC 
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.
Comment 1 Timur Iskhodzhanov 2011-08-17 13:08:42 UTC 
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)
Comment 2 Timur Iskhodzhanov 2011-08-17 13:18:44 UTC 
Terribly sorry: the last comment should have been added to bug 280271
Comment 3 Timur Iskhodzhanov 2011-08-26 09:54:37 UTC 
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
Comment 4 Timur Iskhodzhanov 2011-08-26 09:56:21 UTC 
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