Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AppImage compiled with buildpackage.sh crashes on Fedora 30: Magic number is wrong: 542 #16512

Closed
fusion809 opened this issue May 6, 2019 · 6 comments

Comments

Projects
None yet
2 participants
@fusion809
Copy link
Contributor

commented May 6, 2019

Issue Summary

On Fedora 30, under a GNOME 3.32.1 on Wayland session an AppImage for OpenRA Red Alert commit 83b4e44, built using packaging/linux/buildpackage.sh, crashed with the error:

Exception of type `System.TypeInitializationException`: The type initializer for 'System.Console' threw an exception.
Inner
  Exception of type `System.TypeInitializationException`: The type initializer for 'System.ConsoleDriver' threw an exception.
  Inner
    Exception of type `System.Exception`: Magic number is wrong: 542
      at System.TermInfoReader.ReadHeader (System.Byte[] buffer, System.Int32& position) [0x00028] in <9689214c1e4645be91df75196bac3cbb>:0 
  at System.TermInfoReader..ctor (System.String term, System.String filename) [0x0005f] in <9689214c1e4645be91df75196bac3cbb>:0 
  at System.TermInfoDriver..ctor (System.String term) [0x00055] in <9689214c1e4645be91df75196bac3cbb>:0 
  at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x00000] in <9689214c1e4645be91df75196bac3cbb>:0 
  at System.ConsoleDriver..cctor () [0x0004d] in <9689214c1e4645be91df75196bac3cbb>:0 
    at System.Console.SetupStreams (System.Text.Encoding inputEncoding, System.Text.Encoding outputEncoding) [0x00007] in <9689214c1e4645be91df75196bac3cbb>:0 
  at System.Console..cctor () [0x0008e] in <9689214c1e4645be91df75196bac3cbb>:0 
  at OpenRA.Game.Initialize (OpenRA.Arguments args) [0x00020] in <aa3301db0c694bda9f03d9c08a53a260>:0 
  at OpenRA.Game.InitializeAndRun (System.String[] args) [0x00006] in <aa3301db0c694bda9f03d9c08a53a260>:0 
  at OpenRA.Program.Main (System.String[] args) [0x00044] in <aa3301db0c694bda9f03d9c08a53a260>:0 

System Information

  • Operating System: Fedora 30.
  • .NET / Mono Version: 5.18.1.0.
  • OpenRA Version: commit no 25990, hash 83b4e44.
  • Mod: Red Alert.

How to reproduce

  • On Arch Linux, run make in a fresh copy of this repo checked out at commit 83b4e44.

  • Then cd to packaging/linux.

  • Run ./buildpackage.sh $(git rev-list --branches bleed --count) ~/Applications (naturally, ~/Applications needs to exist).

  • Reboot into a Fedora 30 GNOME 3.32.1 on Wayland session, with access to Arch's ~/Applications directory.

  • Launch the AppImage with ./OpenRA-Red-Alert-devel-x86_64.AppImage.

  • Logs
    https://gist.github.com/abbdfbf1ee1395f3c7a715fefe5c1084 (exception log).

@pchote

This comment has been minimized.

Copy link
Member

commented May 6, 2019

This is a known mono bug that was fixed with 5.12 (we ship 5.10).

We need to either find a solution that lets us ship a more recent version without dropping support for CentOS (preferrable), or if we need a quick workaround adding export TERM=xterm in the AppRun wrapper will probably avoid this.

@pchote pchote added this to the Next Release milestone May 6, 2019

@pchote pchote added the Regression label May 6, 2019

@fusion809

This comment has been minimized.

Copy link
Contributor Author

commented May 6, 2019

Also occurs on Arch it appears; normally on Arch I run OpenRA installed as a package, not from the AppImage, that's why I didn't know 'til now.

@fusion809

This comment has been minimized.

Copy link
Contributor Author

commented May 6, 2019

I think you're right @pchote, I added "export TERM=xterm" to the start of openra.appimage.in and it fixed the error. Guessing I should create a PR with this change.

@pchote

This comment has been minimized.

Copy link
Member

commented May 6, 2019

The mono-5.20.1-ubuntu-14.04-x64 runtime provided by upstream mono only resolves symbols for glibc <= 2.15, so this should be compatible with all our currently supported distros.

Switching the AppImageSupport/macOS/travis configurations to 5.20.1 should therefore be straightforward - this does still mean dropping support for macOS < 10.9 though, so we need to gauge impact from the sysinfo first.

Edit: The sysinfo shows only 7 instances of OpenRA on macOS < 10.9 in 2019.

@fusion809

This comment has been minimized.

Copy link
Contributor Author

commented May 6, 2019

Well it's EOL isn't it? Last update to 10.9 according to Wikipedia was in 2016, so it sounds EOL to me (hence presumably older versions would be too). If you supported every EOL release of the major OSs you'd be making one .... of a hard time for yourselves. Besides, they can still use older releases of OpenRA, which is what you should expect when using an unsupported older release of an OS.

@pchote

This comment has been minimized.

Copy link
Member

commented May 6, 2019

https://github.com/pchote/OpenRA/releases/tag/pkgtest-20190506 includes test builds updated to mono 5.20.1.19

I should be able to PR the changes behind this once they've had a bit more testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.