This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ada/9480: Cannot "kill -TERM" programs that link the tasking runtime [GNAT]


The following reply was made to PR ada/9480; it has been noted by GNATS.

From: Craig Carey <research@ijs.co.nz>
To: report@gnat.com,gcc-gnats@gcc.gnu.org,gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org,oliver.kellogg@sysde.eads.net,gcc-prs@gcc.gnu.org
Cc: Mark Johnson <mark_h_johnson@raytheon.com>,
 David C. Hoos <david.c.hoos.sr@ada95.com>
Subject: Re: ada/9480: Cannot "kill -TERM" programs that link the
  tasking runtime [GNAT]
Date: Mon, 03 Feb 2003 03:27:08 +1300

 Description of Problem in GNAT:
 
 Three extra threads show up when no new tasks are added but there is only an
 added "9.7.2 Timed Entry Call[s]" that unblocks the delay statement if the
 program is being closed. I refer here to the difference between "Version 1"
 and "Version 2" of the program that shows what happens when the TERM signal
 is sent to the program.
 
 
 Background:
 
 A bug report was sent to the GCC bug report system. This message informs
 ACT of the new detail of how 3 of the 4 threads can't be terminated with a
 TERM signal, in both Linux and FreeBSD's Linux emulator.
 
 
 
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl
 
 Here are some test results that confirm that the reported problem in Linux
 existed. A way to get around the problem in GNAT 3.15p Ada (see source
 code below) removes the problem for GNAT's FSU threads. For the GNAT Native
 Linux threads, what was 1 thread is then replaced with 4, the program will
 catch a TERM signal if it is applied to one of the lesser threads of the
 four.
 
 Method of shutting the program down:
 "KILL": kill -s TERM <pid>
 "TERM": kill -s KILL <pid>
 
 --------------------------------------------------------------------------------
 Version 1 of the program:
 This is the program shown in bug report 9480 that was sent to the GCC website.
 The program does not have an Ada TERM-signal Interrupt handler.
 
 Tests 1,2:
 OS=Linux & FreeBSD, Linux 3.15p with FSU threads    :
     TERM Is ignored. (In the corresponding case with the FreeBSD 3.15p compiler,
     the TERM signal is not ignored.) KILL Kills OK.
 
 Tests 3,4:
 OS=Linux & FreeBSD, Linux 3.15p with Native threads :
     TERM is Ignored. KILL Kills. (One thread shows in 'top'.)
 
 Test 5:
 OS=FreeBSD, Executable created by FreeBSD v3.15p Port :
     TERM terminates. KILL Kills.
 
 --------------------------------------------------------------------------------
 Version 2 of the program:
 Version 2 appears below.
 
 
 Tests 6,7:
 OS=Linux & FreeBSD, Linux 3.15p with FSU threads : TERM terminates. KILL kills.
 
 Tests 8,9:
 OS=Linux & FreeBSD, Linux 3.15p with Native threads :
     TERM: Handled OK by 1 of the 4 threads and ignored by the other 3 threads.
     KILL: The program stops with a KILL signal to any of the 4 threads.
 
 Test 10:
 OS=FreeBSD, Executable created by FreeBSD Port of the GNAT v3.15p Ada 95
   compiler:
     TERM: handled OK in Ada OK. KILL Kills.
 
 --------------------------------------------------------------------------------
 
 
 Other information about the testing done:
    * "OS" is an abbreviation for 'operating system'.
    * The Linux was Debian Linux, kernel version 2.4.20. The FreeBSD was v4.7.
    * The compilers were ACT's 3.15p compiler rather than the GCC Ada compiler.
 
 
 Here is version 2 of the program that will stop OK when a "kill -s TERM" is
 done, but only if one of the four threads is the target of the signal.
 
 
 -------------------------------------------------------------------------------
 -------------------------------------------------------------------------------
 with Ada.Text_IO;
 with Sigterm_Ignored;
 
 procedure Sigterm_Ignored_2 is
     package Tio renames Ada.Text_IO;
     package S renames Sigterm_Ignored;
 
     task type Freerun;
 
     task body Freerun is
     begin
        null;
     end Freerun;
 
     Ans   : Boolean;
 begin
     loop
        Tio.Put_Line ("Delaying");
        select
           S.Signals.Shutdown;
           exit;
        or
           delay 1.3;
        end select;
     end loop;
     S.Signals.Interrupt_Was_Received (Ans => Ans);
     Tio.Put_Line ("Quitting. Interrupt was received = " &
              Boolean'Image (Ans));
 end Sigterm_Ignored_2;
 
 -------------------------------------------------------------------------------
 with Ada.Interrupts.Names;
 
 package Sigterm_Ignored is
 
     protected Signals is
        procedure SIGTERM_Handler;
        pragma Interrupt_Handler (SIGTERM_Handler);
        pragma Attach_Handler (SIGTERM_Handler, Ada.Interrupts.Names.SIGTERM);
 
        entry Shutdown;
 
        procedure Interrupt_Was_Received (Ans : out Boolean);
 
     private
        Unblocked   : Boolean := False;
     end Signals;
 
 end Sigterm_Ignored;
 
 -------------------------------------------------------------------------------
 package body Sigterm_Ignored is
 
     protected body Signals is
 
        procedure SIGTERM_Handler is
        begin
           Unblocked := True;
        end SIGTERM_Handler;
 
        entry Shutdown
           when Unblocked is
        begin
           null;
        end Shutdown;
 
        procedure Interrupt_Was_Received (Ans : out Boolean) is
        begin
           Ans := Unblocked;
        end Interrupt_Was_Received;
 
     end Signals;
 
 end Sigterm_Ignored;
 
 -------------------------------------------------------------------------------
 -------------------------------------------------------------------------------
 
 
 
  >From: okellogg@freenet.de (Oliver Kellogg)
  >Newsgroups: comp.lang.ada
  >Subject: tasking programs built with GNAT insensitive to SIGTERM
  >Date: 29 Jan 2003 07:04:07 -0800
  >Organization: http://groups.google.com/
  >Lines: 16
  >Message-ID: <6a6390b8.0301290704.7880bb16@posting.google.com>
  >NNTP-Posting-Date: 29 Jan 2003 15:04:07 GMT
  >
  >Hi,
  >
  >Under Linux, how come tasking programs built with GNAT
  >(3.2, but other versions as well) don't react to
  >"kill -TERM" ?
  >
  >Is there a trick to make them killable?
  >
  >See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl,
  >bug number 9480.
  >
  >Thanks,
  >
  >Oliver
  >
  >-- okellogg at freenet dot de
 
 
 
 
 Below, inside this bug/problem report to the GCC GNU bug reporting system
 and webpage, is the program I named "Version 1" (in some text above).
 
 
 
 A page under http://gcc.gnu.org/cgi-bin/gnatsweb.pl  :
 
 | View Problem Report: 9480
 |
 | or send email to interested parties
 |
 | --------------------------------------------------------------------------------
 | Reporter's email: oliver.kellogg@sysde.eads.net
 | CC these people
 | on PR status email:
 |
 | Number: 9480
 | Category: ada
 | Synopsis: Cannot "kill -TERM" programs that link the tasking runtime
 | Confidential: no
 | Severity: serious
 | Priority: medium
 | Responsible: unassigned
 | State: open
 | Class: sw-bug
 | Submitter-Id: net
 | Arrival-Date: Tue Jan 28 15:06:01 UTC 2003
 | Closed-Date:
 | Last-Modified:
 | Originator: Oliver M. Kellogg
 | Release: gcc-3.2.1
 | Organization:
 | Environment: RedHat Linux 8.0 (i686)
 |
 | Description: A main program that merely contains a task type
 | declaration (but no task object) does not react to
 | the TERM signal.
 | OTOH, A main program without any tasking related
 | declarations reacts normally to the SIGTERM.
 |
 | Here is the test program:
 |
 | -- file: sigterm_ignored.adb
 | with Text_Io;
 |
 | procedure Sigterm_Ignored is
 |
 |    task type Freerun;
 |    -- NB: Only a task TYPE, not even a real task.
 |    task body Freerun is
 |    begin
 |       null;
 |    end Freerun;
 |
 | begin
 |    loop
 |       text_io.put_line ("Here is the main program.");
 |       delay 1.3;
 |    end loop;
 | end Sigterm_Ignored;
 |
 | File Attachments:
 | How-To-Repeat: gnatmake the test program and start it.
 | Then try doing a "kill -TERM" on the process and witness
 | that the program is not terminated.
 |
 | Fix:
 |
 | Release-Note:
 | Unformatted:
 |
 | --------------------------------------------------------------------------------
 |
 | or send email to interested parties
 |
 | Audit Trail:
 |
 ----
 
 Note: if this is rejected by the GNAT problem report handling system of ACT
 then I most likely would not renew the document and resend it.
 
 
 Craig Carey
 New Zealand
 
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]