Re: Allocators and exceptions -- Debugging says memory leak!

[anon@anon.org (anon)]

--
-- Dmitry A. Kazakov suggested in his first post that it was not 
-- only deallocation but finalization.  And in his second post he 
-- re-stated.  But does it the answer for your question.
--
-- For each call to allocation there is a finalization call as well.
--
-- And as you first stated, the answer was not in the AARM. but 
-- allocation with finalization are in the AARM. Now, the AARM also 
-- defines a user accessible hooks for each to allow the user 
-- to monitor these processes and to perform any additional action 
-- if it is needed.
--
-- The following examples are a modified examples of yours. So
-- why are the hooks procedures, not called as Dmitry A. Kazakov 
-- and Ada topic on finalization suggest?
--
-- Now as I suggested in my second post it is an operating 
-- environment in this case a compiler question. 
--
-- How is the statement 
--
--   Ptr := new T (-5);
--
-- evaluate and executed.
--
-- Does the statement first create the record. 
-- Then perform checks on the constant "-5" as the system trys to 
-- assign the value to the record variable C. 
-- If this is the case then a finalization has to take place after 
-- Constraint_Error.
--
-- Or does it perform the checks first.  
-- And because of the raised Constraint_Error the system will 
-- never allocate the memory for the new record. 
-- Which means no finalization is need.
--
-- Denoting its not an allocation, deallocation or finalization 
-- problem but a problem on how Ada and its compilers evaluate a 
-- statement and generate its machine code. This can lead to 
-- memory leaks, which is shown to be true in the example PZ.adb.
-- But this can be manage by altering the program code.
--
--

-- The following package is used to provide finalization hooks
-- used in the examples programs. They only show the hooks are
-- called by display a message.
--
--
-- P1.ads
--
with Ada.Finalization ; 
use  Ada.Finalization ;

package P1 is

   type T ( Init : Integer ) is new Controlled with record
      C : Positive := Positive ( Init ) ;
   end record ;

private

   procedure Initialize ( X : in out T ) ;
   procedure Adjust ( X : in out T ) ;
   procedure Finalize ( X : in out T ) ;

end P1 ;

--
-- P1.adb 
--
with Ada.Text_IO ; 
use  Ada.Text_IO ;

package body P1 is

  procedure Initialize ( X : in out T ) is

   begin
      Put_Line ( "Initialize called." ) ;
   end Initialize ;

  procedure Adjust ( X : in out T ) is

   begin
      Put_Line ( "Adjust called." ) ;
   end Adjust ;

  procedure Finalize ( X : in out T ) is

   begin
      Put_Line ( "Finalize called." ) ;
   end Finalize ;

end P1 ;

-- The following example is modified version of the original 
-- program, that uses the finalization hooks. 
--
-- In executing the program P0, The routine shows that it will 
-- raise Constraint_Error and no allocation or finalization will be 
-- preformed. But if you alter the constant "-5" to a "5". then 
-- finalization hooks will be performed. This also means that the 
-- Constraint_Error has nothing to with the memory allocation or 
-- possible memory leaks.
--
--
-- P0.adb
--
with P1 ;
use  P1 ;

with Ada.Text_IO ;
with Ada.Integer_Text_IO ;

procedure P0 is

   type T_Access is access T;

   Ptr : T_Access;

begin
   Ptr := new T (-5);

   Ada.Integer_Text_IO.Put ( Ptr.all.C ) ;
   Ada.Text_IO.New_Line ;
exception
   when Constraint_Error =>
      -- is memory leaked or deallocated?
      Ada.Text_IO.Put_Line ( "Constraint_Error" ) ;
      null;
end P0 ;


--
-- But does P0, allow memory leaks!
--
-- First, All Ada version should have debugging routines that 
-- the programmer can use to see this.
-- I use GNAT.Debug_Pools.
--
-- This Code shows that there are Memory Leaks in the statement 
--
--   Ptr := new T (-5);  
--
-- The info routine stated in the Constraint_Error block that
-- memory as been allocated but not deallocated in the old 
-- algorithm. Since, the Finalization is never called, this 
-- suggest Memory Leak! And without finalization hooks being 
-- called the program can not reclaim the memory, aka Memory Leak!
--
-- This suggest that the programmer should alter the program 
-- code to force the checking and possible Constraint_Error to 
-- a predictable part of the code that does not require memory 
-- or allow a Memory Leaks!
--
-- which I did in the new algorithm.
--

--
--
-- PZ.adb
--
with P1 ;
use  P1 ;

with Ada.Text_IO ;
with Ada.Integer_Text_IO ;

with GNAT.debug_pools ;
use  GNAT.debug_pools ;
with Ada.Exceptions ;
use  Ada.Exceptions ;

procedure PZ is


  type T_Access is access T;

  --
  -- Debug routine code
  --
  P : GNAT.Debug_Pools.Debug_Pool;
  for T_Access'Storage_pool use P ;

  procedure Info is new GNAT.Debug_Pools.Print_Info
                                ( Ada.Text_IO.Put_Line ) ;

  Ptr : aliased T_Access;

  I : Integer := -5 ;  -- Use for algorithm without memory leaks
  J : Positive ;
  K : Integer ;
  

begin

  --
  -- Algorithm without memory leaks!
  --
  -- In this version the code will generate a Constraint_Error
  -- before any routine needs any memory. Which means no Memory 
  -- Leak!
  --
  Ada.Text_IO.Put_Line ( "New Algorithm" ) ;
  Info ( P ) ;

  begin 
    J := Positive ( I ) ; 
    K := Integer ( J ) ;
    Ptr := new T ( K ) ;

    Ada.Integer_Text_IO.Put ( Ptr.all.C ) ;
    Ada.Text_IO.New_Line ;
  exception
    when Constraint_Error =>
      -- is memory leaked or deallocated?
      Ada.Text_IO.Put_Line ( "Constraint_Error" ) ;
      Info ( P ) ;
      null;
    when E : others => 
      Ada.Text_IO.Put_Line ( "Raised " & Exception_Name ( E ) ) ;
  end ;

  --
  -- Algorithm with memory leaks!
  --
  Ada.Text_IO.Put_Line ( "Old Algorithm" ) ;
  Info ( P ) ;

  Ptr := new T (-5);  

  Ada.Integer_Text_IO.Put ( Ptr.all.C ) ;
  Ada.Text_IO.New_Line ;
  Info ( P ) ;
exception
  when Constraint_Error =>
    -- is memory leaked or deallocated?
    Ada.Text_IO.Put_Line ( "Constraint_Error" ) ;
    Info ( P ) ;
    null;
  when E : others => 
    Ada.Text_IO.Put_Line ( "Raised " & Exception_Name ( E ) ) ;
end PZ;


In <1189323618.588340.87180@o80g2000hse.googlegroups.com>,  Maciej Sobczak <see.my.homepage@gmail.com> writes:
>What happens when during the initialization of the newly allocated
>object an exception is raised?
>
>I cannot find anything in the AARM that covers this case. What I want
>to find exactly is the *guarantee* that the allocated memory is
>automatically reclaimed.
>Any relevant paragraph numbers are highly welcome.
>
>--
>Maciej Sobczak
>http://www.msobczak.com/
>