www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Issue with module destructor order

reply Benjamin Thaut <code benjamin-thaut.de> writes:
Hi,
I came across a issue with the order in which druntime calls the module 
destructors. I created a small repro case for it:

file a.d:
module a;

import logger;

shared static this()
{
   log("a init");
}

shared static ~this()
{
   log("a deinit");
}

file b.d:
module b;

import mix;

class Foo
{
   mixin logIt;
}

file logger.d:
module logger;

import std.stdio;

shared static this()
{
   writefln("logger init");
}

void log(string message)
{
   writefln(message);
}

shared static ~this()
{
   writefln("logger deinit");
}

file main.d:
module main;


import std.stdio;

import a;

import b;



int main(string[] argv)
{
   auto foo = new Foo();

   writefln("main");

   return 0;

}


mix.d:
module mix;

public import logger;

mixin template logIt()
{
   static shared this()
   {
     log(typeof(this).stringof ~ " init");
   }

   static shared ~this()
   {
     log(typeof(this).stringof ~ " deinit");
   }
}

Compile with: dmd a.d b.d logger.d main.d mix.d -oftest.exe
Running gives the following output:

logger init
a init
shared(Foo) init
main
a deinit
logger deinit
shared(Foo) deinit

That means that the logger module destructor is called before the b 
module actually gets destructed which leads to the logger beeing used in 
a destructed state. In my real world case this leads to a fiel operation 
on a closed file handle. Is this intended behaviour or is this a bug? I 
assume this happens because of the mixin template and the public import.
I'm using dmd 2.058.

-- 
Kind Regards
Benjamin Thaut
Mar 26 2012
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Created bug ticket: http://d.puremagic.com/issues/show_bug.cgi?id=7855

-- 
Kind Regards
Benjamin Thaut
Apr 08 2012
prev sibling next sibling parent reply Kevin Cox <kevincox.ca gmail.com> writes:
On Mar 26, 2012 5:11 AM, "Benjamin Thaut" <code benjamin-thaut.de> wrote:

 Is this intended behaviour or is this a bug? I assume this happens


because of the mixin template and the public import.

 I'm using dmd 2.058.

 --
 Kind Regards
 Benjamin Thaut


I don't think the order of destructors is defined. There would be no way to
have semantic control because it wouldn't work when you link different
files together.  The only solution would be to have the compiler analyse
the code and figure out what should be destructed first which would be and
impressive feat.

The solution to solving your problem is not to close the file object in the
destructor and let the OS clean it up when your program terminates.
Apr 08 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/08/2012 02:14 PM, Kevin Cox wrote:

 On Mar 26, 2012 5:11 AM, "Benjamin Thaut" <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>> wrote:
  > Is this intended behaviour or is this a bug? I assume this happens
 because of the mixin template and the public import.
  > I'm using dmd 2.058.
  >
  > --
  > Kind Regards
  > Benjamin Thaut

 I don't think the order of destructors is defined. There would be no way
 to have semantic control because it wouldn't work when you link
 different files together.  The only solution would be to have the
 compiler analyse the code and figure out what should be destructed first
 which would be and impressive feat.


Actually that is what is normally done. (it is quite conservative 
though, cyclical imports where multiple modules have static 
constructors/destructors are just disallowed and terminate the program 
on startup.)


 The solution to solving your problem is not to close the file object in
 the destructor and let the OS clean it up when your program terminates.


This would be a workaround.
Apr 08 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 mixin template logIt()
 {
    static shared this()
    {
      log(typeof(this).stringof ~ " init");
    }

    static shared ~this()
    {
      log(typeof(this).stringof ~ " deinit");
    }
 }


Try "shared static this()" and it won't run as a class constructor.
http://dlang.org/class.html#StaticConstructor
May 23 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 mixin template logIt()
 {
    static shared this()
    {
      log(typeof(this).stringof ~ " init");
    }

    static shared ~this()
    {
      log(typeof(this).stringof ~ " deinit");
    }
 }


Try "shared static this()" and it won't run as a class constructor.
http://dlang.org/class.html#StaticConstructor
May 23 2012