https://issues.dlang.org/show_bug.cgi?id=14863
--- Comment #2 from Steven Schveighoffer <[email protected]> --- According to clock_getres, it should return -1 with a value of EINVAL for errno. So this seems like an issue with the kernel. I've never heard of a system call causing a segfault like this. However, I noticed that we have an assert(0) if that happens. This shouldn't be the way it's handled. If we get the "Invalid clock" return value, we should only assert if someone actually tries to USE that clock (put in some sort of sentinel value for the resolution). In addition, we should be checking the kernel version and only doing CLOCK_BOOTTIME, if the kernel version is high enough (and skipping otherwise, put in the sentinel value). I still think lazy initialization is incorrect. Jonathan, I see it's assigned to you, I can look into this if you want. (In reply to Jonathan M Davis from comment #1) > I guess that in one of the rounds of changes that we made > relating to static constructor bugs must have resulted in the clock > frequency being grabbed for all of the ClockTypes that the system supports > (or at least supposedly supports). *sigh* If you recall, it was because of the issue with static constructors being used in templates cause any importing module to be flagged as containing static constructors. So we now construct all the resolutions eagerly (which shouldn't cause issues like this). I think lazy initialization is not what we need, when someone uses an "unsupported" clock, they should not get a segfault either. Neither would the original solution of only eagerly fetching clocks that are instantiated (the segfault would then occur in a static ctor). The only correct answer is to eliminate the segfault. --
