Is array concatenation allowed in the class destructor?

Maxim Fomin maxim at maxim-fomin.ru
Wed Jan 2 10:32:04 PST 2013


On Wednesday, 2 January 2013 at 18:09:34 UTC, Ali Çehreli wrote:
> This issue has come up on the D.learn forum recently. The 
> following program terminates with 
> core.exception.InvalidMemoryOperationError. (Tested with dmd 
> 2.061 and 2.060)
>
> string foo()
> {
>     return "a";
> }
>
> class Foo
> {
>     ~this()
>     {
>         auto s = foo() ~ "b";
>     }
> }
>
> void main()
> {
>     new Foo;
> }

It is obvious that dtor causes GC activity and current GC is not 
reentrant. If you change dtor to for e.x. ~this() { 
doSomething(); }, so now it is impossible to make conclusion 
without doSomething() source.

> My guess is that the destructor is being executed at a point 
> where the runtime is not in a state where allocating memory is 
> allowed.

Yes.

> Has the programmer made a mistake? What operations are safe in 
> a class destructor? (I think the question is valid for the 
> destructors of GC-owned struct objects as well.)

In general, operations that involve GC inside class dtors that 
are run after garbage process have been started, lead to 
InvalidMemoryOperationError exceptions. This means that if you 
cannot guarantee that class destructors are called before garbage 
collection, you will have problems.

> Since the programmer should not be expected to know the 
> implementations of every function, the only safe action is to 
> not call any function in a destructor at all, as that function 
> may be allocating dynamic memory under certain conditions. I 
> hope I am wrong. :) Can we expect the runtime be cooperative 
> until all finalizers are executed?
>
> Ali

Yes, necessity to restrict operations in class dtors are 
inconvenient. The solution is to fix the GC.


More information about the Digitalmars-d mailing list