Re: Problems with controlled types, gnatmem thinks handle is leaking memory (long)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 21 Feb 2005 20:12:34 +0000, Simon Wright wrote:

> "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:
> 
>> On Sun, 20 Feb 2005 19:09:02 +0100, Dmitry A. Kazakov wrote:
> 
>>> In Finalize: I check if Ref_Count = 0 before decrementing and raise
>> 
>> No need to check for the reference count to be 0, as it can never go
>> negative and if it does, there's a problem with the code.
> 
> I believe it is possible for an object to be Finalized more than once.

In the case of a handle it is not a problem because its Finalize is sort of

if pointer /= null then
   decrement reference count;
   if reference count = 0 then
      free object (and pointer is null);
   else
      pointer := null;
   end if;
end if;

Thus, when called again Finalize would do nothing.

>>> if the Ref_Count is zero upon object's finalization. That helps a
>>> lot!
>> 
>> I suppose I could raise an exception if the reference count isn't
>> zero on finalisation, hmmm...but surely there would be an error in
>> the code if that were not the case? Surely it's another example of
>> what I mentioned above, it should never go wrong as long as the
>> initialize, adjust & finalize subprograms have been implemented
>> correctly.
> 
> It isn't a good idea to propagate an exception out of a Finalize
> operation (it's a bounded error to do so, 7.6.1(14)).

Yes, but here (when the reference count is not zero) it is too late to
undertake anything. The exception just signals a fatal error. In this sense
it is already a bounded error to get here. It is as bad as Segmentation
Fault. The only thing one can do is to abort the program with all its tasks
as soon as possible. I raise Program_Error, though it would be nice to have
an exception that isn't propagated, but kills the partition at the spot...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de