Deallocating an object twice

Deallocating an object twice

[Victor Porton]

If I understand correctly, it is an undefined behavior (or is it called 
unbounded error?) if a pool access is deallocated twice with 
Unchecked_Deallocation.

I think it should be a Program_Error (if checks are on).

Why was not this done even in Ada2012 (not speaking about older Ada)?

It's bad.

Or is it done and I just miss it?

-- 
Victor Porton - http://portonvictor.org

Re: Deallocating an object twice

[Victor Porton]

Victor Porton wrote:

> If I understand correctly, it is an undefined behavior (or is it called
> unbounded error?) if a pool access is deallocated twice with
> Unchecked_Deallocation.
> 
> I think it should be a Program_Error (if checks are on).
> 
> Why was not this done even in Ada2012 (not speaking about older Ada)?
> 
> It's bad.
> 
> Or is it done and I just miss it?

The same should be done if attempt to deallocate an access which never has 
been allocated (for example, if it is an aliased object on the stack).

-- 
Victor Porton - http://portonvictor.org

Re: Deallocating an object twice

[Randy Brukardt]

"Victor Porton" <porton@narod.ru> wrote in message 
news:lr11gd$log$2@speranza.aioe.org...
> Victor Porton wrote:
>
>> If I understand correctly, it is an undefined behavior (or is it called
>> unbounded error?) if a pool access is deallocated twice with
>> Unchecked_Deallocation.
>>
>> I think it should be a Program_Error (if checks are on).
>>
>> Why was not this done even in Ada2012 (not speaking about older Ada)?
>>
>> It's bad.
>>
>> Or is it done and I just miss it?
>
> The same should be done if attempt to deallocate an access which never has
> been allocated (for example, if it is an aliased object on the stack).
>
> -- 
> Victor Porton - http://portonvictor.org 

Re: Deallocating an object twice

[Randy Brukardt]

"Victor Porton" <porton@narod.ru> wrote in message 
news:lr11gd$log$2@speranza.aioe.org...
> Victor Porton wrote:
>
>> If I understand correctly, it is an undefined behavior (or is it called
>> unbounded error?) if a pool access is deallocated twice with
>> Unchecked_Deallocation.
>>
>> I think it should be a Program_Error (if checks are on).
>>
>> Why was not this done even in Ada2012 (not speaking about older Ada)?
>>
>> It's bad.
>>
>> Or is it done and I just miss it?
>
> The same should be done if attempt to deallocate an access which never has
> been allocated (for example, if it is an aliased object on the stack).

In both cases, how would you tell? An access type is just a raw pointer. We 
do such a check in Janus/Ada when we can, but it can be reliably detected in 
only a small percentage of cases. (And if the storage pool is user-defined, 
it's up to the storage pool to deal with this -- the language can't do 
anything.)

There's a reason it's called UNCHECKED_Deallocation, after all.

                                         Randy.

Re: Deallocating an object twice

[Simon Wright]

Victor Porton <porton@narod.ru> writes:

> If I understand correctly, it is an undefined behavior (or is it called 
> unbounded error?) if a pool access is deallocated twice with 
> Unchecked_Deallocation.
>
> I think it should be a Program_Error (if checks are on).
>
> Why was not this done even in Ada2012 (not speaking about older Ada)?
>
> It's bad.
>
> Or is it done and I just miss it?

If done at all, this check would be at a low level. AdaCore offer a
Debug Pool facility[1]. Of course, this wouldn't detect a C program
using free() on data allocated in Ada; you'd have to go lower, perhaps
using a tool like valgrind[2].

[1]
https://gcc.gnu.org/onlinedocs/gnat_ugn_unw/The-GNAT-Debug-Pool-Facility.html
[2] http://valgrind.org

Re: Deallocating an object twice

[anon]

For most OS, deallocation of memory happens only if the program 
exits and returns it's allocated resources back to the OS. And 
for speed the underlying C library routine "free" does not truly
deallocate or mark the memory as unused. Which means passing a 
null pointer to the underlying C library function "free" will not 
generate an error, so neither does Ada.  This is apart of a bigger 
topic call "Garbage Collection".

Note: In the GNAT design if a storage pool is not present, the 
memory access is done by calling "System.Memory.Free" routine 
which only calls the underlying C library. So, no exception 
will be generated.

To correct this and limit the number of memory leaks, a program 
may employ a storage pool ( like the generic abstract package 
System.Storage_Pool ), and add the exception in the deallocation 
routine. But this feature does have this down sides, like slower 
speed and larger footprint for maintaining a allocation tables.

Note: GNAT does have a number of storage pools designs.

As for the exception it would fall under the Storage_Error scope.
The "Program_Error" exception are for special cases. 


In <lr1142$log$1@speranza.aioe.org>, Victor Porton <porton@narod.ru> writes:
>If I understand correctly, it is an undefined behavior (or is it called 
>unbounded error?) if a pool access is deallocated twice with 
>Unchecked_Deallocation.
>
>I think it should be a Program_Error (if checks are on).
>
>Why was not this done even in Ada2012 (not speaking about older Ada)?
>
>It's bad.
>
>Or is it done and I just miss it?
>
>-- 
>Victor Porton - http://portonvictor.org

Re: Deallocating an object twice

[Peter Chapin]

On 2014-07-27 07:30, anon@att.net wrote:

> For most OS, deallocation of memory happens only if the program 
> exits and returns it's allocated resources back to the OS. And 
> for speed the underlying C library routine "free" does not truly
> deallocate or mark the memory as unused.

C's free() marks the memory as unused in the sense that a future call to
malloc() might use memory that was previously freed. If that were not
the case it wouldn't be possible, even in principle, to write a C
program that didn't leak memory.

What you're talking about is happening at a lower level. It may be the
case that once a block of memory is requested from the OS, the C library
never releases it. As you say, the OS reclaims the memory when the
process terminates. However, the C library will still distinguish
between used and unused memory within the allocation it has.

A program that loops forever repeatedly allocating and freeing memory
for a single integer, say, could run infinitely without ever exhausting
storage or requesting additional memory from the OS. It will simply
reuse the space it already has.

Peter

Re: Deallocating an object twice

[Stephen Leake]

Victor Porton <porton@narod.ru> writes:

> If I understand correctly, it is an undefined behavior (or is it called 
> unbounded error?) if a pool access is deallocated twice with 
> Unchecked_Deallocation.

You misunderstand.

ARM 2012 13.11.3

Procedure Free has the following effect:

7
     1.  After executing Free(X), the value of X is null.

8
     2.  Free(X), when X is already equal to null, has no effect.


-- 
-- Stephe

Re: Deallocating an object twice

[Victor Porton]

Stephen Leake wrote:

> Victor Porton <porton@narod.ru> writes:
> 
>> If I understand correctly, it is an undefined behavior (or is it called
>> unbounded error?) if a pool access is deallocated twice with
>> Unchecked_Deallocation.
> 
> You misunderstand.
> 
> ARM 2012 13.11.3
> 
> Procedure Free has the following effect:
> 
> 7
>      1.  After executing Free(X), the value of X is null.
> 
> 8
>      2.  Free(X), when X is already equal to null, has no effect.

No, it is that you misunderstand me:

Second free may be executed not as Free(X) but as Free(Y) where Y was a copy 
of X (and so Free(X) sets only X to null, it does not set Y to null; and 
Free(Y) would be erroneous).

-- 
Victor Porton - http://portonvictor.org

Re: Deallocating an object twice

[Stephen Leake]

Victor Porton <porton@narod.ru> writes:

> Stephen Leake wrote:
>
>> Victor Porton <porton@narod.ru> writes:
>> 
>>> If I understand correctly, it is an undefined behavior (or is it called
>>> unbounded error?) if a pool access is deallocated twice with
>>> Unchecked_Deallocation.
>> 
>> You misunderstand.
>> 
>> ARM 2012 13.11.3
>> 
>> Procedure Free has the following effect:
>> 
>> 7
>>      1.  After executing Free(X), the value of X is null.
>> 
>> 8
>>      2.  Free(X), when X is already equal to null, has no effect.
>
> No, it is that you misunderstand me:
>
> Second free may be executed not as Free(X) but as Free(Y) where Y was a copy 
> of X (and so Free(X) sets only X to null, it does not set Y to null; and 
> Free(Y) would be erroneous).

Ok, that makes sense. 

Don't copy pointers! It is the copy of the pointer that is bad, not the
behavior of Unchecked_Deallocation.

-- 
-- Stephe

Re: Deallocating an object twice

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Don't copy pointers! It is the copy of the pointer that is bad, not
> the behavior of Unchecked_Deallocation.

I don't think pointers are always bad, so long as everyone knows whose
responsibility it is to do the allocation and deallocation.