Cycle detected between modules with ctors/dtors

Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Mar 4 08:06:50 PST 2015


On 3/3/15 4:24 PM, rumbu wrote:
> On Tuesday, 3 March 2015 at 18:55:49 UTC, Steven Schveighoffer wrote:
>
>>>
>>> Only one of the listed modules has a static contructor
>>> (system.globalization) and that constructor doesn't use any information
>>> from other modules.
>>
>> It's a complex problem. Because we don't control the linker, we cannot
>> establish an order of execution for the module system. It must be a
>> directed acyclic graph. Although, cycles are allowed that only involve
>> a single module with ctor/dtors, or with no ctor/dtors. But we have to
>> detect it at runtime during startup.
>>
>> two of those modules should have static ctor or dtor (they may have
>> either to cause the error).
>>
>>> The message is not too helpful, I have no clue where to start searching
>>> for the error source, the source code has more than 25k LOC. In fact, I
>>> don't believe this error is true, since I have only two non-linked
>>> modules with static contructors.
>>
>> Just look for "static this" and "static ~this" inside those files
>> identified.
>>
>>
>> -Steve
>
> One of the listed modules had a ctor. Another one - curiously - not
> listed in the cyclic error - had a static dtor, and this module was
> imported by two of them.

curiously not listed? That doesn't make any sense. If there is not a 
cycle in the listed modules, where at least 2 modules have a static ctor 
or static dtor, then there is a bug in the cycle detection code.

>
> Anyway, reduced case scenario:
>
> module a;
> import b;
> static this();
> -----
> module b;
> import a;
> static ~this();
>
> As I supposed, this is a false error, the order of execution seems very
> clear to me, but not for the runtime. Even if I have two ctors, I think
> it's better to relax this rule, maybe the constructors are not dependent
> one of each other to have cyclic errors. In my case, one of the
> constructors loads some resources bound to the executable and the
> destructor is simply a winapi call to CoUninitialize, totally unrelated.
>
>

Clearly, the above is not an issue, but at the moment, the code treats 
having a ctor and having a dtor as the same thing. How to fix it? I'm 
not exactly sure, you need to have the modules sorted according to ctor 
and also according to dtor. The runtime is supposed to run dtors in 
reverse order from ctor calls, and I think we should not break that. But 
there is definitely room to allow for reordering when ctors are not 
affected.

I'll have to think about it some more.

-Steve


More information about the Digitalmars-d-learn mailing list