From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,1583af5ff29435e5
X-Google-Attributes: gid103376,public
From: Florian Weimer <fw@deneb.cygnus.argh.org>
Subject: Re: Dynamic allocation of tasks
Date: 2000/03/28
Message-ID: <87aejj8rbv.fsf@deneb.cygnus.argh.org>#1/1
X-Deja-AN: 603314676
References: <87r9d3gvix.fsf@deneb.cygnus.argh.org>
 <8basg1$627$1@nnrp1.deja.com> <87ya7aewb8.fsf@deneb.cygnus.argh.org>
 <slrn8di1sp.jt.lutz@taranis.iks-jena.de>
 <874s9yd6s2.fsf@deneb.cygnus.argh.org> <wcc1z4wnjrw.fsf@world.std.com>
Mail-Copies-To: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@cygnus.argh.org
X-Trace: deneb.cygnus.argh.org 954229924 24863 192.168.1.2 (28 Mar 2000
 07:52:04 GMT)
Organization: Penguin on board
User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.6
Mime-Version: 1.0
Reply-To: Florian Weimer <fw-usenet@deneb.cygnus.argh.org>
NNTP-Posting-Date: 28 Mar 2000 07:52:04 GMT
Newsgroups: comp.lang.ada
Date: 2000-03-28T07:52:04+00:00
List-Id: <comp.lang.ada>

Robert A Duff <bobduff@world.std.com> writes:

> I didn't see your exact program, so I don't know what's going on.

As I wrote earlier, I think I've identified the problem (it's not
about task not reacting to abort, but about terminated tasks not being
deallocated properly).  Robert Dewar made a cryptic comment which I
didn't understand, and perhaps it's really an Ada issue (and not a
GNAT one; it shows up on Solaris as well, BTW).  The following program
allocates more and more memory:

procedure Test_Leak is

   procedure Use_Tasks is
      task type Some_Task;
      task body Some_Task is
      begin
         null;
      end;

      type Task_Array is array (1 .. 1) of Some_Task;
      TA : Task_Array;
   begin
      null;
   end;

begin
   loop
      Use_Tasks;
   end loop;
end;

Each elaboration of the declaration of TA allocates a few storage
elements which are never freed.  The problem disappears if the tasks
is not wrapped within an array (which is probably the reason why no
one has noticed it before).

Of course, this behavior is fully conforming with the letters of the
RM (simply because the RM doesn't talk about storage leaks, except
that an instance of Ada.Unchecked_Deallocation "should actually
reclaim storage" ;), but I wonder whether it violates the spirit of
the RM...