Discussion:
[arch-general] OpenRA / Mono exceptions
Alajos Odoyle
2018-03-02 10:34:42 UTC
Permalink
Hi all,

When trying to run OpenRA from the community repository or when building
the package myself (using the community PKGBUILD) I get Mono exceptions
like the one below [1]. At first I thought it could be an upstream issue
but sure enough it builds just fine when using a clean chroot. As I did
not customize the mono package and cannot think of anything else causing
this (configuration?), i hope someone here might have some ideas. NB, I
never used Mono before - it was auto-installed as a dependency of OpenRA.

Thanks,
Alajos

[1]: Unhandled Exception:
System.TypeInitializationException: The type initializer for
'System.Console' threw an exception. --->
System.TypeInitializationException: The type initializer for
'System.ConsoleDriver' threw an exception. ---> System.Exception: Magic
number is wrong: 542
at System.TermInfoReader.ReadHeader (System.Byte[] buffer,
System.Int32& position) [0x00028] in <a84b655e5e6a49ee96b338ec792f5580>:0
at System.TermInfoReader..ctor (System.String term, System.String
filename) [0x0005f] in <a84b655e5e6a49ee96b338ec792f5580>:0
at System.TermInfoDriver..ctor (System.String term) [0x00055] in
<a84b655e5e6a49ee96b338ec792f5580>:0
at System.ConsoleDriver.CreateTermInfoDriver (System.String term)
[0x00000] in <a84b655e5e6a49ee96b338ec792f5580>:0
at System.ConsoleDriver..cctor () [0x0004d] in
<a84b655e5e6a49ee96b338ec792f5580>:0
--- End of inner exception stack trace ---
at System.Console.SetupStreams (System.Text.Encoding inputEncoding,
System.Text.Encoding outputEncoding) [0x00007] in
<a84b655e5e6a49ee96b338ec792f5580>:0
at System.Console..cctor () [0x0008e] in
<a84b655e5e6a49ee96b338ec792f5580>:0
--- End of inner exception stack trace ---
at Mono.CSharp.Driver.Main (System.String[] args) [0x00019] in
<2b1e99ce45b54209bdcdab138d9758ae>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException:
The type initializer for 'System.Console' threw an exception. --->
System.TypeInitializationException: The type initializer for
'System.ConsoleDriver' threw an exception. ---> System.Exception: Magic
number is wrong: 542
at System.TermInfoReader.ReadHeader (System.Byte[] buffer,
System.Int32& position) [0x00028] in <a84b655e5e6a49ee96b338ec792f5580>:0
at System.TermInfoReader..ctor (System.String term, System.String
filename) [0x0005f] in <a84b655e5e6a49ee96b338ec792f5580>:0
at System.TermInfoDriver..ctor (System.String term) [0x00055] in
<a84b655e5e6a49ee96b338ec792f5580>:0
at System.ConsoleDriver.CreateTermInfoDriver (System.String term)
[0x00000] in <a84b655e5e6a49ee96b338ec792f5580>:0
at System.ConsoleDriver..cctor () [0x0004d] in
<a84b655e5e6a49ee96b338ec792f5580>:0
--- End of inner exception stack trace ---
at System.Console.SetupStreams (System.Text.Encoding inputEncoding,
System.Text.Encoding outputEncoding) [0x00007] in
<a84b655e5e6a49ee96b338ec792f5580>:0
at System.Console..cctor () [0x0008e] in
<a84b655e5e6a49ee96b338ec792f5580>:0
--- End of inner exception stack trace ---
at Mono.CSharp.Driver.Main (System.String[] args) [0x00019] in
<2b1e99ce45b54209bdcdab138d9758ae>:0
make: *** [Makefile:278: OpenRA.Game.exe] Error 1
Dan Haworth
2018-03-02 10:38:28 UTC
Permalink
Post by Alajos Odoyle
Hi all,
When trying to run OpenRA from the community repository or when
building the package myself (using the community PKGBUILD) I get Mono
exceptions like the one below [1]. At first I thought it could be an
upstream issue but sure enough it builds just fine when using a clean
chroot. As I did not customize the mono package and cannot think of
anything else causing this (configuration?), i hope someone here might
have some ideas. NB, I never used Mono before - it was auto-installed
as a dependency of OpenRA.
Thanks,
Alajos
System.TypeInitializationException: The type initializer for
'System.Console' threw an exception. --->
System.TypeInitializationException: The type initializer for
Magic number is wrong: 542
  at System.TermInfoReader.ReadHeader (System.Byte[] buffer,
System.Int32& position) [0x00028] in <a84b655e5e6a49ee96b338ec792f5580>:0
  at System.TermInfoReader..ctor (System.String term, System.String
filename) [0x0005f] in <a84b655e5e6a49ee96b338ec792f5580>:0
  at System.TermInfoDriver..ctor (System.String term) [0x00055] in
<a84b655e5e6a49ee96b338ec792f5580>:0
  at System.ConsoleDriver.CreateTermInfoDriver (System.String term)
[0x00000] in <a84b655e5e6a49ee96b338ec792f5580>:0
  at System.ConsoleDriver..cctor () [0x0004d] in
<a84b655e5e6a49ee96b338ec792f5580>:0
   --- End of inner exception stack trace ---
  at System.Console.SetupStreams (System.Text.Encoding inputEncoding,
System.Text.Encoding outputEncoding) [0x00007] in
<a84b655e5e6a49ee96b338ec792f5580>:0
  at System.Console..cctor () [0x0008e] in
<a84b655e5e6a49ee96b338ec792f5580>:0
   --- End of inner exception stack trace ---
  at Mono.CSharp.Driver.Main (System.String[] args) [0x00019] in
<2b1e99ce45b54209bdcdab138d9758ae>:0
The type initializer for 'System.Console' threw an exception. --->
System.TypeInitializationException: The type initializer for
Magic number is wrong: 542
  at System.TermInfoReader.ReadHeader (System.Byte[] buffer,
System.Int32& position) [0x00028] in <a84b655e5e6a49ee96b338ec792f5580>:0
  at System.TermInfoReader..ctor (System.String term, System.String
filename) [0x0005f] in <a84b655e5e6a49ee96b338ec792f5580>:0
  at System.TermInfoDriver..ctor (System.String term) [0x00055] in
<a84b655e5e6a49ee96b338ec792f5580>:0
  at System.ConsoleDriver.CreateTermInfoDriver (System.String term)
[0x00000] in <a84b655e5e6a49ee96b338ec792f5580>:0
  at System.ConsoleDriver..cctor () [0x0004d] in
<a84b655e5e6a49ee96b338ec792f5580>:0
   --- End of inner exception stack trace ---
  at System.Console.SetupStreams (System.Text.Encoding inputEncoding,
System.Text.Encoding outputEncoding) [0x00007] in
<a84b655e5e6a49ee96b338ec792f5580>:0
  at System.Console..cctor () [0x0008e] in
<a84b655e5e6a49ee96b338ec792f5580>:0
   --- End of inner exception stack trace ---
  at Mono.CSharp.Driver.Main (System.String[] args) [0x00019] in
<2b1e99ce45b54209bdcdab138d9758ae>:0
make: *** [Makefile:278: OpenRA.Game.exe] Error 1
I had the same issue, seems to be related to the following bug
https://github.com/mono/mono/issues/6752. I downgraded ncurses to 6.0 to
get things going again.

--dan
Alajos Odoyle
2018-03-02 11:17:57 UTC
Permalink
Post by Dan Haworth
I had the same issue, seems to be related to the following bug
https://github.com/mono/mono/issues/6752. I downgraded ncurses to 6.0 to
get things going again.
--dan
Thanks, that was quick! I also had to install libtinfo5 (AUR) and
symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 (I guess
alternatively rebuilding Mono or something could work). Cheers!
Dan Haworth
2018-03-02 11:38:33 UTC
Permalink
Post by Alajos Odoyle
Post by Dan Haworth
I had the same issue, seems to be related to the following bug
https://github.com/mono/mono/issues/6752. I downgraded ncurses to 6.0
to get things going again.
--dan
Thanks, that was quick! I also had to install libtinfo5 (AUR) and
symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 (I guess
alternatively rebuilding Mono or something could work). Cheers!
I play a LOT of OpenRA ;)

Glad it solved your issue!

--dan
Levente Polyak via arch-general
2018-03-02 12:07:14 UTC
Permalink
Post by Dan Haworth
Post by Alajos Odoyle
Post by Dan Haworth
I had the same issue, seems to be related to the following bug
https://github.com/mono/mono/issues/6752. I downgraded ncurses to
6.0
Post by Alajos Odoyle
Post by Dan Haworth
to get things going again.
--dan
Thanks, that was quick! I also had to install libtinfo5 (AUR) and
symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 (I guess
alternatively rebuilding Mono or something could work). Cheers!
I play a LOT of OpenRA ;)
Glad it solved your issue!
--dan
That's literally an incredibly stupid idea. Symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 does not magically make it compatible for both, it is ABI incompatible that's the whole point of a soname bump. Anything linking to libtinfo.so.6 may now be broken in one or the other way. never ever overwrite existing versioned so libs with any other version.
Alajos Odoyle
2018-03-03 16:56:52 UTC
Permalink
Post by Levente Polyak via arch-general
That's literally an incredibly stupid idea. Symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 does not magically make it compatible for both, it is ABI incompatible that's the whole point of a soname bump. Anything linking to libtinfo.so.6 may now be broken in one or the other way. never ever overwrite existing versioned so libs with any other version.
It will do until the fix made it into the Arch Linux Mono package. The
reason for this message was to let people know that I had no issues
applying this hack *so far*. People can decide for themselves if they
want to do it quick and dirty or not-so-quick and properly (the latter
which I referred to as "rebuilding Mono or something"). Calling the idea
"incredibly stupid" is just unnecessary.
Doug Newgard via arch-general
2018-03-03 17:14:17 UTC
Permalink
On Sat, 3 Mar 2018 17:56:52 +0100
Post by Alajos Odoyle
Post by Levente Polyak via arch-general
That's literally an incredibly stupid idea. Symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 does not magically make it compatible for both, it is ABI incompatible that's the whole point of a soname bump. Anything linking to libtinfo.so.6 may now be broken in one or the other way. never ever overwrite existing versioned so libs with any other version.
It will do until the fix made it into the Arch Linux Mono package. The
reason for this message was to let people know that I had no issues
applying this hack *so far*. People can decide for themselves if they
want to do it quick and dirty or not-so-quick and properly (the latter
which I referred to as "rebuilding Mono or something"). Calling the idea
"incredibly stupid" is just unnecessary.
You may think it's unnecessary, but he's not wrong. Posting the info in the
first place is the same as encouraging others to do something incredibly
stupid, to the point where I would consider it malicious.
Guus Snijders via arch-general
2018-03-03 17:27:29 UTC
Permalink
Op za 3 mrt. 2018 18:14 schreef Doug Newgard via arch-general <
Post by Doug Newgard via arch-general
On Sat, 3 Mar 2018 17:56:52 +0100
[symlink lib version]
It will do until the fix made it into the Arch Linux Mono package. [...]
You may think it's unnecessary, but he's not wrong. Posting the info in the
first place is the same as encouraging others to do something incredibly
stupid, to the point where I would consider it malicious.
So, for future reference it's probably better to use LD_PRELOAD instead of
/lib (although the rest is the same).

The main potential problem here is users who may not know exactly what
they're doing and just copy/paste snippets they find online.


Mvg, Guus
Eli Schwartz via arch-general
2018-03-04 00:43:33 UTC
Permalink
Post by Alajos Odoyle
Post by Levente Polyak via arch-general
That's literally an incredibly stupid idea. Symlink
/usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 does not magically
make it compatible for both, it is ABI incompatible that's the whole
point of a soname bump. Anything linking to libtinfo.so.6 may now be
broken in one or the other way. never ever overwrite existing
versioned so libs with any other version.
It will do until the fix made it into the Arch Linux Mono package. The
reason for this message was to let people know that I had no issues
applying this hack *so far*. People can decide for themselves if they
want to do it quick and dirty or not-so-quick and properly (the latter
which I referred to as "rebuilding Mono or something"). Calling the idea
"incredibly stupid" is just unnecessary.
The worst problem with symlinking incompatible libraries together is
that strictly speaking, the result is "undefined behavior", not "omg
this segfaults everywhere".

The undefined behavior in question may be segfaults, but it can just as
easily be the application silently doing the wrong thing. So the fact
that you are not aware of any issues, is not necessarily an indicator
that there were in fact no issues.

This is the other reason why it is stupid to do this, in addition to the
one where you are subtly encouraging people who don't understand the
issue to emulate you without knowing why.
--
Eli Schwartz
Bug Wrangler and Trusted User
Guus Snijders via arch-general
2018-03-04 12:50:08 UTC
Permalink
Post by Alajos Odoyle
Post by Dan Haworth
I had the same issue, seems to be related to the following bug
https://github.com/mono/mono/issues/6752. I downgraded ncurses to 6.0 to
get things going again.
--dan
Thanks, that was quick! I also had to install libtinfo5 (AUR) and
symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 (I guess
alternatively rebuilding Mono or something could work). Cheers!
Just out of curiosity; could you try deleting the symlink and LD_preloading
/usr/lib/libtifinfo.so.5 ?

The current replies on the ML are a technically correct, though a bit blunt.
If the preload tricks actually works, we could advice the next user a bit
better ;).


Mvg, Guus Snijders
Alajos Odoyle
2018-03-04 15:31:37 UTC
Permalink
Post by Guus Snijders via arch-general
Just out of curiosity; could you try deleting the symlink and LD_preloading
/usr/lib/libtifinfo.so.5 ?
The current replies on the ML are a technically correct, though a bit blunt.
If the preload tricks actually works, we could advice the next user a bit
better ;).
Mvg, Guus Snijders
I tried and it does not work unfortunately.

Cheers!
Guus Snijders via arch-general
2018-03-05 11:22:28 UTC
Permalink
Post by Guus Snijders via arch-general
Post by Guus Snijders via arch-general
Just out of curiosity; could you try deleting the symlink and
LD_preloading
Post by Guus Snijders via arch-general
/usr/lib/libtifinfo.so.5 ?
The current replies on the ML are a technically correct, though a bit
blunt.
Post by Guus Snijders via arch-general
If the preload tricks actually works, we could advice the next user a bit
better ;).
Mvg, Guus Snijders
I tried and it does not work unfortunately.
Lol, ok. Thanks for trying.


Mvg, Guus Snijders

Loading...