https://issues.dlang.org/show_bug.cgi?id=17037
safety0ff.bugz <safety0ff.b...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86_64 |All OS|Linux |All --- Comment #3 from safety0ff.bugz <safety0ff.b...@gmail.com> --- Seems to be a race involving the global scheduler: __gshared Scheduler scheduler; @property ref ThreadInfo thisInfo() nothrow { 1: if ( scheduler is null ) 2: return ThreadInfo.thisInfo; 3: return scheduler.thisInfo; } If a thread sets scheduler to null after another has evaluated line 1 to false but hasn't run line 3, then the other thread tries to run scheduler.thisInfo with a null scheduler. I'm not sure what the design is for the global scheduler is with regard to concurrent access. I.e. I'm wondering if all the `scheduler is null` checks be changed to: auto lscheduler = atomicLoad(scheduler); if (lscheduler is null) return ...; lscheduler. ... // --