The problem is that when invoking on the 2nd version of get_cur_time_ms on one of my projects (as a dependent crate for the final project crate) in release mode, it crashes with 311 illegal hardware instruction. And this only happens recently when I upgrade rustup and crates versions (including libc to 0.2.36). However, when I tried to write a minimal working example by adding a main for the code snippets above, it does not crash.
Am I using libc the wrong way to get the current time?
If not, what are the possible reasons of this crash?
BTW, I admit it may not be good idea to specialize Linux x86_64 function in this way since the performance differences may be negligible, however I would like to know the possible root causes of the crash.
It should be the use of 2nd version of get_cur_time_ms since: when I directly use 1st version there is no crash and the logging message ends before the call of this function although another logging is immediately after this function call.
Unfortunately I don’t know what the instruction is.
Yes, I updated rust nightly from rustup, nightly-2018-05-21-x86_64-unknown-linux-gnu. However it might start working wrongly about ten days ago (I update rust weekly but cannot remember exact version) when I upgraded the OS from Ubuntu 16.04 to Ubuntu 18.04.
I think this could be caused by use of mem::uninitialized(). LLVM’s optimizer is known to sometimes do funny things with code that uses uninitialized memory, such as assuming that said memory region cannot be accessed and replacing code that accesses it with garbage.
To test this hypothesis, you can replace calls to mem::uninitialized() with calls to mem::zeroed() and see if it fixes your problem.
Note that this error (I assume) derived from having received a SIGILL signal. The most common cause of that is an alignment fault, rather than (as the text implies) trying to execute a bad machine opcode.