• rkreis (48/48) Jul 21 2007 Good day.

rkreis <elite01 gmx.de> writes:

Good day.

Using derelict, I noticed bad behavior: The app segfaulted inside of 
destructors. I later found out that derelict unloaded libraries and the 
destructor, freeing resources, tried to call such unloaded functions. 
This happens because a static destructor unloads all libraries. A simple 
test case shows that static destructors can be called before all 
instances are destructed. If an instance destructor then uses resources 
freed by the static destructor, things become problematic.

import std.stdio;

class Dude {
	private static char[] eek;

	public this() {
		writefln("Dude ctor");
	}

	public ~this() {
		writefln("Dude dtor - eek is '%s'", eek);
	}

	public static this() {
		writefln("Dude static ctor");
		eek = "Everything up and running";
	}

	public static ~this() {
		writefln("Dude static dtor");
		eek = "You're doomed";
	}
}

void main() {
	Dude d = new Dude();
}
outputs
Dude static ctor
Dude ctor
Dude static dtor
Dude dtor - eek is 'You're doomed'

with GDC 0.23 and DMD 1.018. This shows that the instance destructor 
accesses a static variable that has been modified by the static 
destructor. I can't think of any workaround.
In my opinion, it would be better if static destructors were only called 
after all unreachable class instances have been destructed. That 
wouldn't break static destructors accessing static references to class 
instances.
If one of those classes also depends on the static destructor not having 
run, that's a circular dependency to which I can't find a satisfying 
solution. For those cases, I suggest the current behavior, or a compile 
time error (which is hard to implement, I believe). Anyway, easily 
accessing static variables after the static destructor has run doesn't 
sound right.

See you soon.