InvalidMemoryOperationError when calling functions from destructors

Steven Schveighoffer schveiguy at yahoo.com
Sun Apr 28 07:44:31 PDT 2013


On Sat, 27 Apr 2013 07:58:25 -0700, Vladimir Panteleev  
<vladimir at thecybershadow.net> wrote:

> On Saturday, 27 April 2013 at 06:12:03 UTC, Steven Schveighoffer wrote:
>> On Thu, 25 Apr 2013 10:57:13 -0700, Vladimir Panteleev  
>> <vladimir at thecybershadow.net> wrote:
>>
>>> On Thursday, 25 April 2013 at 16:17:57 UTC, Jacob Carlborg wrote:
>>>> You cannot access GC controlled memory in class destructors.
>>>
>>> Not true.
>>
>> Can you be more specific?  Maybe the wording was too strong.  Should  
>> say "you shouldn't access GC controlled memory in class destructors."
>>
>> Or are you thinking of some specific case?  Because the opposite of the  
>> above is DEFINITELY not true.  I just want to make that clear.
>
> Last time I checked, destructors were called separately from  
> deallocation. Thus, referencing memory will not result in undefined  
> behavior. The order of destruction is non-deterministic, but otherwise,  
> it's the same as accessing a clear()'d object, which is perfectly safe  
> (from a memory safety perspective).

No, destructors are called along with deallocation.  At the moment, the GC  
mutex is held while the collection is in progress, so it's not possible  
that a deallocated block could be reallocated before a dtor that  
references that block is called.  But that is an implementation detail.   
There is no requirement for the GC to behave that way.  In addition, there  
is no requirement for the GC to run in a specific thread, so if a  
destroyed object references a non-destroyed object, it's possible some  
thread is using the non-destroyed object while the dtor is using it in  
another thread, even if the object was only ever accessed from one thread!

-Steve


More information about the Digitalmars-d mailing list