|Anonymous | Login | Signup for a new account||2018-02-20 23:20 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002025||Core Inform||Releasing, bibliographic data, cBlorb||public||2017-08-11 02:27||2017-10-21 21:25|
|Target Version||Fixed in Version|
|Summary||0002025: ni crashes trying to get time of day on latest Linux kernels|
|Description||The ni story compiler for Linux is a statically-linked Linux binary. The 6M62 binary is linked against an older version of glibc that implements the gettimeofday() syscall using the vsyscall mechanism. In the latest Linux kernels, the vsyscall mechanism has been disabled by default for security reasons. As a result, ni will crash right at startup when invoked in any way.|
|Minimal Source Text To Reproduce|
Run ni on a Linux box with kernel 4.11.
|Additional Information||The category of this bug report is obviously wrong. I didn't see an appropriate option.|
The 6L38 binary is linked against an even older version of glibc, and thus works fine.
A workaround for the 6M62 crash is to set vsyscall=emulate kernel option. This has mild security implications, but makes ni work again (tested).
Easiest real fix is to recompile ni with a current glibc.
(If ni were open-sourced that would be ideal, of course.)
Is there some reason ni is stripped? Not doing so would make debugging this kind of thing easier.
|Tags||No tags attached.|
|Effect||(critical) Compiler crashes|
|I just ran into this myself. This is extremely high priority. I can't believe this has been left to fester for nearly two months; it shows callous disregard for the userbase by the ni authors.|
|@pchimento Do you have the ability to recompile this, or does it need Graham?|
I have a recompiled ni binary for x86_64 available here: https://www.dropbox.com/s/w7j9ly6b9q7bvf0/ni?dl=0 [^]
This should allow people to fix their installations for the time being. Replace the existing ni binary in /usr/libexec/gnome-inform7 (location may vary per Linux distribution) with this one. Or, build gnome-inform7 from a git checkout after dropping this ni binary into the src/ni/ folder.
Hopefully there will be a re-release of ni on all supported architectures before too long; I can only provide x86_64, lacking the hardware to provide the others. When that happens, I'll issue a full re-release of gnome-inform7.
It comes with a few caveats.
- One test from Inform's test suite failed with this recompiled binary. No idea how serious it is. I'm leaving on vacation imminently, so I really don't have time to dig into it. Obviously before making a re-release we'd have to make sure this isn't an issue.
- If anyone decides to make a re-release of one of the gnome-inform7 packages with this binary (see https://github.com/ptomato/gnome-inform7/wiki/Packaging [^]) please differentiate it by including something like "unofficial" in the version string.
PS. Neroden: that's not helpful and not likely to make others want to help you.
Philip, which architectures are in fact supported? Is it just x86_64, i386, ppc32, and arm6 w/hardfloat?
I have a fair amount of practice in cross-compiling; I restructured the configure scripts for gcc a few years ago, which involved extensive cross-compile testing. I could even test that the binary runs on i386, though I don't have hardware or simulators to test the others.
A rebuilt all-architectures is at https://drive.google.com/file/d/0BzKIVhv2dkRYMmFzdGJMbHRlWGs/view?usp=sharing [^]
ppc32 is still the original one--I destroyed my ppc32 system trying to get it to current Debian stable. The other three architectures have been rebuilt and the test suite run; x86 and x86_64 each fail one test case where the exponential function returns 0.999999 rather than 1.0. I figure if you're trying to do precision floating point in Inform 7 you have worse problems than one part per million.
Once I figure out again how to upload to the I7 site (or Philip or someone does it for me) it will be available from the Inform7 site.
Those are currently the only architectures available as they're the only ones I have ready access to.
|adam: Your build still tries to call vsyscall for time of day. Not sure why. Can confirm that yours crashes unless I have vsyscall=emulate on my Linux box.|
|pchimento: Your binary seems to be compiled correctly to avoid vsyscall . Thanks much.|
Well, that's annoying. That's been compiled on Debian Stretch, fully updated on the 13th of October 2017.
I can try compiling on something like the current Ubuntu but it may take a little while.
|adam: It's about both kernel version and glibc version. What ones do you have of these? I'm looking at Linux 4.13.0-1 and libc6 2.24-17 . Maybe the static linking is grabbing an older libc.a or something? I don't know.|
|2017-08-11 02:27||PO8||New Issue|
|2017-08-15 22:46||PO8||Issue Monitored: PO8|
|2017-09-28 22:24||neroden||Note Added: 0004723|
|2017-09-29 11:47||zarf||Relationship added||has duplicate 0002030|
|2017-10-04 03:59||curiousdannii||Note Added: 0004727|
|2017-10-04 04:00||curiousdannii||Status||new => confirmed|
|2017-10-06 14:04||pchimento||Note Added: 0004728|
|2017-10-10 20:05||neroden||Note Added: 0004731|
|2017-10-13 18:43||adam||Note Added: 0004735|
|2017-10-21 18:58||PO8||Note Added: 0004740|
|2017-10-21 19:07||PO8||Note Added: 0004741|
|2017-10-21 19:50||adam||Note Added: 0004742|
|2017-10-21 21:25||PO8||Note Added: 0004743|
|Copyright © 2000 - 2010 MantisBT Group|