MantisBT - Core Inform
View Issue Details
0002025Core InformReleasing, bibliographic data, cBlorbpublic2017-08-11 02:272018-06-09 17:19
PO8 
 
highcriticalalways
confirmedopen 
x86LinuxAny
6M62 
 
(critical) Compiler crashes
0002025: ni crashes trying to get time of day on latest Linux kernels
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.
Run ni on a Linux box with kernel 4.11.
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.
No tags attached.
has duplicate 0002030closed  Gnome Inform application NI segfaults on every invocation 
Issue History
2017-08-11 02:27PO8New Issue
2017-08-15 22:46PO8Issue Monitored: PO8
2017-09-28 22:24nerodenNote Added: 0004723
2017-09-29 11:47zarfRelationship addedhas duplicate 0002030
2017-10-04 03:59curiousdanniiNote Added: 0004727
2017-10-04 04:00curiousdanniiStatusnew => confirmed
2017-10-06 14:04pchimentoNote Added: 0004728
2017-10-10 20:05nerodenNote Added: 0004731
2017-10-13 18:43adamNote Added: 0004735
2017-10-21 18:58PO8Note Added: 0004740
2017-10-21 19:07PO8Note Added: 0004741
2017-10-21 19:50adamNote Added: 0004742
2017-10-21 21:25PO8Note Added: 0004743
2018-04-06 12:20MarcNote Added: 0004770
2018-04-06 13:32adamNote Added: 0004771
2018-05-28 05:11MarcNote Added: 0004775
2018-05-28 22:32adamNote Added: 0004778
2018-05-29 17:10adamNote Added: 0004779
2018-05-29 18:39zarfNote Added: 0004780
2018-05-29 18:45adamNote Added: 0004781
2018-06-09 17:19adamNote Added: 0004782

Notes
(0004723)
neroden   
2017-09-28 22:24   
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.
(0004727)
curiousdannii   
2017-10-04 03:59   
@pchimento Do you have the ability to recompile this, or does it need Graham?
(0004728)
pchimento   
2017-10-06 14:04   
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.
(0004731)
neroden   
2017-10-10 20:05   
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.
(0004735)
adam   
2017-10-13 18:43   
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.
(0004740)
PO8   
2017-10-21 18:58   
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.
(0004741)
PO8   
2017-10-21 19:07   
pchimento: Your binary seems to be compiled correctly to avoid vsyscall . Thanks much.
(0004742)
adam   
2017-10-21 19:50   
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.
(0004743)
PO8   
2017-10-21 21:25   
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.
(0004770)
Marc   
2018-04-06 12:20   
Is there any plan on making a new release which contains a fix for this issue?
(0004771)
adam   
2018-04-06 13:32   
I can try again on ARM and x86_64. My last i386 machine died a few months ago.
(0004775)
Marc   
2018-05-28 05:11   
adam: any luck? pchimento's binary seems to work fine on Windows Linux Subsystem.
(0004778)
adam   
2018-05-28 22:32   
I have rebuilt for amd64 and it seems to work OK on the two most recent Amazon AMIs, which is somewhat promising. I am in the midst of building (very slowly) on a Raspberry Pi.

I may have enough bits and pieces to build an i386 machine, but I won't have that rebuilt for a while. I'll ask how to re-upload the image.
(0004779)
adam   
2018-05-29 17:10   
Here's something interesting. I was able to do an i386 build on sorta-kinda Ubuntu 18.04, (an Ubuntu 16.04 updated _in situ_ from Xubuntu 18.04 mini iso), and got the immediate segfault and backtrace with nothing helpful other than vsyscall().

However, if you drop the "k" from the Inform 6 compilation options, it gets through the build. So I think it's got something to do with generating the gameinfo.dbg file.

Even before I manage to get the new images uploaded, you can easily test this out by changing line 522 of the "i7" Perl script from:

    my $i6opts = "-kE2w";

to

    my $i6opts = "-E2w";

I don't know what deleterious effects not using -k would have, or if this is anything other than my own systems' strangeness, but it might be worth a try.

In the version I am planning on uploading, I've added some logic to detect i686 and drop the "k" if found. I don't know if it's actually a reasonable workaround, but at least it isn't any more broken.

kernel is 4.15.0-22-generic #24 Ubuntu SMP, ldd is Ubuntu GLIBC 2.27-3ubuntu1 .
(0004780)
zarf   
2018-05-29 18:39   
It's the Inform 6 binary that's crashing? People should be able to rebuild that from source for themselves if necessary.
(0004781)
adam   
2018-05-29 18:45   
Well, it is for me, now. But I wasn't even seeing the crash previously. So clearly it's very dependent on particular kernel and glibc versions.
(0004782)
adam   
2018-06-09 17:19   
New I7_6M62_Linux_all.tar.gz is uploaded to the inform7 site. Here's hoping it works for other people as well.