[Bug runtime/6030] stap, staprun, stapio interaction quirks: stale module left unloaded

anithra anithra@linux.vnet.ibm.com
Thu Jul 17 13:28:00 GMT 2008


fche at redhat dot com wrote:
> ------- Additional Comments From fche at redhat dot com  2008-07-10 17:04 -------
> (In reply to comment #9)
>   
>> The signal(SIG_CHLD, SIG_IGN) would result in the STAP process ignoring the
>> SIG_CHLD signal. Wont this result in the stap process running forever, waiting
>> for an explicit signal?. In case of the stapgui i want to terminate the stap
>> process, and along with it the stapio process. 
>>     
>
> Could you use   kill (SIGTERM, - stap_pid)  so you broadcast the signal
> to the process group?
>
>   
Hi Frank,

kill(SIGTERM, -stap_pid) solves the problem from the StapGUI point of 
view. I'm able to terminate both the stap& stapio process and thereby 
unload the module.
But the behaviour of the stap process still doesn't seem correct. If a 
signal is sent to the stap process it terminates leaving stapio running 
as a zombie and the module still loaded.
I'm attaching a patch that will solve the problem. Here i'm just 
passing  the signal received by the stap process to the process group, 
so that stapio can unload the module and terminate.

Regards,
Anithra

---
 main.cxx |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: systemtap/main.cxx
===================================================================
--- systemtap.orig/main.cxx
+++ systemtap/main.cxx
@@ -260,7 +260,7 @@ printscript(systemtap_session& s, ostrea
 int pending_interrupts;

 extern "C"
-void handle_interrupt (int /* sig */)
+void handle_interrupt (int  sig)
 {
   pending_interrupts ++;
   if (pending_interrupts > 1) // XXX: should be configurable? time-based?
@@ -268,6 +268,7 @@ void handle_interrupt (int /* sig */)
       char msg[] = "Too many interrupts received, exiting.\n";
       int rc = write (2, msg, sizeof(msg)-1);
       if (rc) {/* Do nothing; we don't care if our last gasp went out. 
*/ ;}
+      kill(0,sig);
       _exit (1);
    }
 }




More information about the Systemtap mailing list