Possible Memory Leak

Possible Memory Leak

[R A Matthews]

This is probably one for the language lawyers...

Consider a type having a pointer to itelf - that
is each variable of this type contains its own
address; it's not limited so it needs to be 
controlled - as exemplified by:

type My_Type;

type Access_My_Type is access all My_Type;

type My_Type is new Ada.Finalization.Controlled with
record
   Self : Access_My_Type;
end record;

Initialize will set Self, and Adjust will
maintain it.

In addition, the type can point to some data:

type My_Type is new Ada.Finalization.Controlled with
record
   Self : Access_My_Type;
   Data : Access_Some_Data_Type;
end record;

Each variable of My_Type points to its own set of data
so Adjust must copy that data and Finalize must deallocate
it.

Now the Annotated Reference Manual at 7.6(21 and 21.b) allows
a compiler to perform assignment on such a data type
via an intermediate temporary variable:

The temporary is overwritten from the source variable,
then Adjust called for the temporary.
The temporary is copied to the target variable then
Adjust is called for the target - but only if the data
type has an aliased component, so we need to
have our data type redeclared as:

type Inner_Type is
record
   Self : Access_My_Type;
   Data : Access_Some_Data_Type;
end record;

type My_Type is new Ada.Finalization.Controlled with
record
   Inner : aliased Inner_Type;
end record;

This ensures that the target of the assignment
is adjusted, so Self is set correctly and gives
the target its own copy of the referenced data.

BUT the Standard says that the temporary variable need
not be finalized, in which case the temporary's
data is not deallocated and so we have a memory leak.

It seems that the Standard is OK when we have
1) Just the Self component, or
2) Just the Data component, though without the use
   of "aliased".

However the Standard is not OK when we have:
3) Both Self and Data (whether or not we have
   used "aliased").
4) Just the Data component and also have an
   aliased component.

Is the Standard wrong?

Enlightenment please!

Robert A. Matthews

ada at ramatthews dot free-online dot co dot uk

Re: Possible Memory Leak

[Brian May]

>>>>> "R" == R A Matthews <ram@noone.nowhere> writes:

    R> This ensures that the target of the assignment is adjusted, so
    R> Self is set correctly and gives the target its own copy of the
    R> referenced data.

    R> BUT the Standard says that the temporary variable need not be
    R> finalized, in which case the temporary's data is not
    R> deallocated and so we have a memory leak.

Noone has responded - strange; I will bite.

I don't claim to be any expert, and I don't claim to completely
understand the problem either, but I suspect you are imagining a
problem where no problem exists.

The compiler will manage allocation and deallocation of temporary
variables, as required for you. If in doubt, either print a message in
each routine and see when it is executed, or look at the assembler
code.

In a previous post, I said:

Arr(1) := Empty expands into:

+ Temp := Empty;        -- shallow copy
+ Finalize(Arr(1));
+ Arr(1) := Temp;       -- shallow copy
+ Adjust(Arr(1));

This could also be written as:

+ Temp := Empty;        -- shallow copy
+ Finalize(Arr(1));
+ Adjust(Temp);
+ Arr(1) := Temp;       -- shallow copy

Where you can see that Temp is adjusted, and not finalised, but no
memory leak occurs either.

(disclaimer: I didn't check if this is what happens, however nobody
accused me of getting it wrong either...).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Possible Memory Leak

[RAMatthews]

Brian May wrote:

> 
> The compiler will manage allocation and deallocation of temporary
> variables, as required for you. If in doubt, either print a message in
> each routine and see when it is executed, or look at the assembler
> code.
> 

Thanks for the response.

But note that its the ARM's wording that bothers me (my
code works OK with GNAT).

It was on noticing those paragraphs (7.6(21.x)) that made
me wonder if my code might encounter a problem with a
different compiler - and indeed whether the Standard is
correct.

Robert A. Matthews

ada at ramatthews dot free-online dot co dot uk

Re: Possible Memory Leak

[Randy Brukardt]

"RAMatthews" <ramatthews@noone.nowhere> wrote in message
news:41a38ae3$0$43611$ed2e19e4@ptn-nntp-reader04.plus.net...
> But note that its the ARM's wording that bothers me (my
> code works OK with GNAT).
>
> It was on noticing those paragraphs (7.6(21.x)) that made
> me wonder if my code might encounter a problem with a
> different compiler - and indeed whether the Standard is
> correct.

A general remark: if you have a problem with the wording of the Standard,
it's always a good idea to check the cross-reference listing of AIs to see
if there is already an issue open for the paragraph in question. That way,
you can see if you have found something new, or are just rediscovering an
already known issue. See http://www.ada-auth.org/AI-XREF.HTML#Section .

                Randy Brukardt
                ARG Editor

Re: Possible Memory Leak

[Randy Brukardt]

"R A Matthews" <ram@noone.nowhere> wrote in message
news:fealnc.6t.ln@127.0.0.1...
> This is probably one for the language lawyers...
...
> Is the Standard wrong?

Yes. We ran across this when we were developing Claw; the (now) SofCheck
front-end followed the Standard language to the letter, and its a mess. We
tried to fix the wording in the Corrigendum, but it took a long time to get
it right, so it had to wait for the Amendment (that is, Ada 2005). See
AI-147. (You'll note that there is a lot more confused in this area than
just 7.6.1(21).)

                Randy Brukardt

Re: Possible Memory Leak

[RAMatthews]

Randy Brukardt wrote:
> "R A Matthews" <ram@noone.nowhere> wrote in message
> news:fealnc.6t.ln@127.0.0.1...
> 
>>This is probably one for the language lawyers...
> 
> ...
> 
>>Is the Standard wrong?
> 
> 
> Yes. We ran across this when we were developing Claw; the (now) SofCheck
> front-end followed the Standard language to the letter, and its a mess. We
> tried to fix the wording in the Corrigendum, but it took a long time to get
> it right, so it had to wait for the Amendment (that is, Ada 2005). See
> AI-147. (You'll note that there is a lot more confused in this area than
> just 7.6.1(21).)
> 
>                 Randy Brukardt
> 

Thank you.

With AI-147 in mind, I will assume that for the type of problem
in my orginal posting:
1) Where a compiler uses a temporary for assignment, then Adjust
    and Finalize are applied so that the target variable is adjusted
    and no memory leaks occur.
2) It is not necessary to introduce an aliased component just to
    make this work - so no use of Inner_Type, as in my original
    posting.



Robert A. Matthews