[arch-general] OpenRA / Mono exceptions
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
On 02/03/18 10:34, Alajos Odoyle wrote:
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
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
On 2018-03-02 11:38, Dan Haworth wrote:
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!
On 02/03/18 11:17, Alajos Odoyle wrote:
On 2018-03-02 11:38, Dan Haworth wrote:
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
On March 2, 2018 12:38:33 PM GMT+01:00, Dan Haworth <dan@xigen.co.uk> wrote:
On 02/03/18 11:17, Alajos Odoyle wrote:
On 2018-03-02 11:38, Dan Haworth wrote:
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
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.
On 2018-03-02 13:07, Levente Polyak via arch-general wrote:
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.
On Sat, 3 Mar 2018 17:56:52 +0100 Alajos Odoyle <alajos.odoyle@pskx.net> wrote:
On 2018-03-02 13:07, Levente Polyak via arch-general wrote:
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.
Op za 3 mrt. 2018 18:14 schreef Doug Newgard via arch-general < arch-general@archlinux.org>:
On Sat, 3 Mar 2018 17:56:52 +0100 Alajos Odoyle <alajos.odoyle@pskx.net> wrote:
On 2018-03-02 13:07, Levente Polyak via arch-general wrote:
[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
On 03/03/2018 11:56 AM, Alajos Odoyle wrote:
On 2018-03-02 13:07, Levente Polyak via arch-general wrote:
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
Op vr 2 mrt. 2018 12:18 schreef Alajos Odoyle <alajos.odoyle@pskx.net>:
On 2018-03-02 11:38, Dan Haworth wrote:
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
On 2018-03-04 13:50, Guus Snijders via arch-general wrote:
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!
Op zo 4 mrt. 2018 16:31 schreef Alajos Odoyle <alajos.odoyle@pskx.net>:
On 2018-03-04 13:50, Guus Snijders via arch-general wrote:
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.
Lol, ok. Thanks for trying. Mvg, Guus Snijders
participants (6)
-
Alajos Odoyle
-
Dan Haworth
-
Doug Newgard
-
Eli Schwartz
-
Guus Snijders
-
Levente Polyak