Non esiste un "processo interno" come sia valgrind stesso che il programma client che esegue in un singolo processo.
I segnali inviati a tale processo verranno recapitati normalmente al programma client. Se il segnale fa in modo che il processo sia terinato, i normali gestori di uscita di valgrind eseguiranno e (ad esempio) segnaleranno eventuali perdite.
Così, per esempio, se cominciamo Valgrind su un comando di sonno:
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==
poi uccidere quel comando:
bericote [~] % kill -TERM 9774
allora il processo sarà uscire e gestori di uscita di valgrind verrà eseguito:
==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
L'unica eccezione sarebbe per kill -9
come in quel caso il pro il processo viene ucciso dal kernel senza essere mai informato del segnale, quindi valgrind non ha alcuna possibilità di fare qualcosa.
Ho provato 'kill -SIGTERM' prima di chiedere, ma ci voleva molto tempo prima che valgrind si fermasse (~ 10 min.), Quindi sospettavo che non avrebbe funzionato. Grazie per la tua risposta. –
Il ritardo è la scansione di tutta la memoria allocata cercando di risolvere se ci sono perdite - che potrebbe richiedere più tempo del normale perché un programma nel mezzo di esecuzione è probabile che abbia più memoria allocata di una che esce normalmente. – TomH
Questo non è vero su OS X 10.7.5 e valgrind-3.8.1. valgrind ignorerà felicemente l'uccisione. –