34

Killing the valgrind process itself leaves no report on the inner process' execution.

Is it possible to send a terminate signal to a process running inside valgrind?

Antonio Pérez
  • 6,702
  • 4
  • 36
  • 61

1 Answers1

32

There is no "inner process" as both valgrind itself and the client program it is running execute in a single process.

Signals sent to that process will be delivered to the client program as normal. If the signal causes the process to terinate then valgrind's normal exit handlers will run and (for example) report any leaks.

So, for example, if we start valgrind on a sleep command:

bericote [~] % valgrind sleep 240
==9774== Memcheck, a memory error detector
==9774== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==9774== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==9774== Command: sleep 240
==9774== 

then kill that command:

bericote [~] % kill -TERM 9774

then the process will exit and valgrind's exit handlers will run:

==9774== 
==9774== HEAP SUMMARY:
==9774==     in use at exit: 0 bytes in 0 blocks
==9774==   total heap usage: 30 allocs, 30 frees, 3,667 bytes allocated
==9774== 
==9774== All heap blocks were freed -- no leaks are possible
==9774== 
==9774== For counts of detected and suppressed errors, rerun with: -v
==9774== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[1]    9774 terminated  valgrind sleep 240

The only exception would be for kill -9 as in that case the process is killed by the kernel without ever being informed of the signal so valgrind has no opportunity to do anything.

TomH
  • 8,900
  • 2
  • 32
  • 30
  • 1
    I tried `kill -SIGTERM` before asking, but it was taking a reaaally long time for valgrind to stop (~10 min.), so I suspected it wouldn't work. Thanks for your answer. – Antonio Pérez Sep 07 '11 at 07:00
  • The delay is it scanning all the allocated memory trying to work out if there are any leaks - that may well take longer than normal because a program in the middle of running is likely to have more memory allocated than one which exits normally. – TomH Sep 07 '11 at 07:44
  • 8
    This isn't true on OS X 10.7.5 and valgrind-3.8.1. valgrind will happily ignore the kill. – Kyle Maxwell Apr 02 '13 at 23:03
  • this doesn't seem to work for me on ubuntu 14 with valgrind 3.8. the process was terminated without proper log – Bill Yan Feb 03 '18 at 01:53
  • Centos: kill -SIGTERM (or SIGUSR1, SIGUSR2) stopped valgrind with summary. – Prashanth Sriram Mar 28 '18 at 09:44