https://issues.dlang.org/show_bug.cgi?id=14863

--- Comment #1 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
Great... People are still using kernels that old? This sort of problem didn't even occur to me. We really aren't set up to have different C headers depending on the kernel version and the like, and we're certainly not set up to support different ClockTypes depending on your kernel version - though in theory, it's supposed to be set up so that if you don't explicitly use a particular ClockType, it wouldn't matter.

The GC and runtime should only care about MonoTime itself - i.e. MonoTimeImpl!(ClockType.normal) and not any of the other instantiations of MonoTimeImpl. 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*

The simplest solution of course would be to simply get rid of ClockType.bootTime, though that definitely would suck, and I don't know how we'd decide when to readd it (I really don't want to have start worrying about kernel versions). Other than that, presumably, we have to make sure that none of the ClockTypes other than ClockType.normal get used in any way unless someone uses them in their own program.

I guess that I'll have to find time to dig into this ASAP.

--

https://issues.dlang.org/show_bug.cgi?id=14863

--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=14863

Marc Schütz <schuetzm@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schuetzm@gmx.net

--- Comment #3 from Marc Schütz <schuetzm@gmx.net> ---
`assert(0);` becomes a `HTL` instruction with -release, which in turn triggers SIGSEGV. That's probably the cause.

--

https://issues.dlang.org/show_bug.cgi?id=14863

--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Marc Schütz from comment #3)
> `assert(0);` becomes a `HTL` instruction with -release, which in turn triggers SIGSEGV. That's probably the cause.

OH! then this is easily fixable.

I thought an assert(0) in release mode still did an assert. We just need to
change how we treat that specific failure. Interestingly, assert(0,
somemessage) seems to be a waste of somemessage. We may want to consider what
assert(0) should do (another topic).

--

https://issues.dlang.org/show_bug.cgi?id=14863

Gerald Jansen <jansen.gerald@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jansen.gerald@gmail.com

--- Comment #5 from Gerald Jansen <jansen.gerald@gmail.com> ---
(In reply to Marc Schütz from comment #3)
> `assert(0);` becomes a `HTL` instruction with -release, which in turn triggers SIGSEGV. That's probably the cause.

Please note that the segfault occurs even without -release, i.e. "dmd hello.d".

--

https://issues.dlang.org/show_bug.cgi?id=14863

--- Comment #6 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Gerald Jansen from comment #5)
> Please note that the segfault occurs even without -release, i.e. "dmd hello.d".

Right, but druntime *is* compiled in release mode. If you compiled druntime in non-release mode, you would see the assert error instead.

--

https://issues.dlang.org/show_bug.cgi?id=14863

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|issues.dlang@jmdavisProg.co |schveiguy@yahoo.com
                   |m                           |

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
PR: https://github.com/D-Programming-Language/druntime/pull/1336

--

https://issues.dlang.org/show_bug.cgi?id=14863

github-bugzilla@puremagic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--

https://issues.dlang.org/show_bug.cgi?id=14863

--- Comment #8 from github-bugzilla@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/d1f382652b8d319e9c055287f082b28e9399a926 Fix issue 14863

https://github.com/D-Programming-Language/druntime/commit/0ca25648947bb8f27d08dc618f23ab86fddea212 Merge pull request #1336 from schveiguy/fixboottimelinux

Fix issue 14863 - CLOCK_BOOTTIME should be optional to support <2.6.39 kernels

--

https://issues.dlang.org/show_bug.cgi?id=14863

Ali Cehreli <acehreli@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acehreli@yahoo.com

--- Comment #9 from Ali Cehreli <acehreli@yahoo.com> ---
Are we sure this bug is fixed? (I've built dmd from git head.) My older kernel still segfaults when initializing MonoTime:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004ad881 in _d_initMonoTime ()
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.149.el6_6.7.x86_64
(gdb) bt
#0  0x00000000004ad881 in _d_initMonoTime ()
#1  0x72656b616d6b756c in ?? ()
#2  0x0000000000000008 in ?? ()
#3  0x00000000006d9fc0 in ?? ()
#4  0x0000000000000000 in ?? ()

$ cat /proc/version Linux version 2.6.32-504.23.4.el6.x86_64

$ dmd --version
DMD64 D Compiler v2.068-devel-286906b

Is there a workaround?

Thank you,
Ali

--