* Deallocating an object twice
@ 2014-07-26 19:55 Victor Porton
2014-07-26 20:02 ` Victor Porton
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Victor Porton @ 2014-07-26 19:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-26 19:55 Deallocating an object twice Victor Porton
@ 2014-07-26 20:02 ` Victor Porton
2014-07-27 2:39 ` Randy Brukardt
2014-07-27 2:42 ` Randy Brukardt
2014-07-27 8:31 ` Simon Wright
` (2 subsequent siblings)
3 siblings, 2 replies; 11+ messages in thread
From: Victor Porton @ 2014-07-26 20:02 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-26 20:02 ` Victor Porton
@ 2014-07-27 2:39 ` Randy Brukardt
2014-07-27 2:42 ` Randy Brukardt
1 sibling, 0 replies; 11+ messages in thread
From: Randy Brukardt @ 2014-07-27 2:39 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-26 20:02 ` Victor Porton
2014-07-27 2:39 ` Randy Brukardt
@ 2014-07-27 2:42 ` Randy Brukardt
1 sibling, 0 replies; 11+ messages in thread
From: Randy Brukardt @ 2014-07-27 2:42 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-26 19:55 Deallocating an object twice Victor Porton
2014-07-26 20:02 ` Victor Porton
@ 2014-07-27 8:31 ` Simon Wright
2014-07-27 11:30 ` anon
2014-07-27 15:29 ` Stephen Leake
3 siblings, 0 replies; 11+ messages in thread
From: Simon Wright @ 2014-07-27 8:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-26 19:55 Deallocating an object twice Victor Porton
2014-07-26 20:02 ` Victor Porton
2014-07-27 8:31 ` Simon Wright
@ 2014-07-27 11:30 ` anon
2014-07-27 12:47 ` Peter Chapin
2014-07-27 15:29 ` Stephen Leake
3 siblings, 1 reply; 11+ messages in thread
From: anon @ 2014-07-27 11:30 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-27 11:30 ` anon
@ 2014-07-27 12:47 ` Peter Chapin
0 siblings, 0 replies; 11+ messages in thread
From: Peter Chapin @ 2014-07-27 12:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-26 19:55 Deallocating an object twice Victor Porton
` (2 preceding siblings ...)
2014-07-27 11:30 ` anon
@ 2014-07-27 15:29 ` Stephen Leake
2014-07-27 15:34 ` Victor Porton
3 siblings, 1 reply; 11+ messages in thread
From: Stephen Leake @ 2014-07-27 15:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-27 15:29 ` Stephen Leake
@ 2014-07-27 15:34 ` Victor Porton
2014-07-28 15:15 ` Stephen Leake
0 siblings, 1 reply; 11+ messages in thread
From: Victor Porton @ 2014-07-27 15:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-27 15:34 ` Victor Porton
@ 2014-07-28 15:15 ` Stephen Leake
2014-07-28 16:15 ` Simon Wright
0 siblings, 1 reply; 11+ messages in thread
From: Stephen Leake @ 2014-07-28 15:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Deallocating an object twice
2014-07-28 15:15 ` Stephen Leake
@ 2014-07-28 16:15 ` Simon Wright
0 siblings, 0 replies; 11+ messages in thread
From: Simon Wright @ 2014-07-28 16:15 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-07-28 16:15 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-26 19:55 Deallocating an object twice Victor Porton
2014-07-26 20:02 ` Victor Porton
2014-07-27 2:39 ` Randy Brukardt
2014-07-27 2:42 ` Randy Brukardt
2014-07-27 8:31 ` Simon Wright
2014-07-27 11:30 ` anon
2014-07-27 12:47 ` Peter Chapin
2014-07-27 15:29 ` Stephen Leake
2014-07-27 15:34 ` Victor Porton
2014-07-28 15:15 ` Stephen Leake
2014-07-28 16:15 ` Simon Wright
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox