roluncher Segmentation fault.

[Elanor]

I'm trying to run latest Regnum Online on a core i5 with 16GB of ram and intel video running a fresh fedora 24 installation. the only output i get is a segmentation fault message. it used to work perfectly on Ubuntu 16.04
The link os for the strace output. Any help greatly appreciated.
https://drive.google.com/open?id=0B3oA9dMR_JYoNEY2TzllTF9QTEU

[_Enio_]

You need to use the new launcher from this post (https://www.championsofregnum.com/forum/showpost.php?p=1862154&postcount=7).

It hasit fixed already, it will auto-update to a even never version, but that one should get you to that updating.

Edit: You need the 64Bit one, just copy it over the current one in regnum folder (usually located in your home folder).
Edit2: You might also need the libjpeg62 and libpng12 libraries.

I did bundle those for another user on dropbox >>here<< (https://www.dropbox.com/s/t6sfy5udirsn9rj/regnum.tar.gz?dl=0). It contains rolauncher and those 2 libs for x86_64, just put it in regnum folder overwriting rolauncher.

[Adrian]

Hi Elanor,

This is already solved, as Enio stated, but sadly the installer is not updated yet (we're doing that in the following days when we finish another fix we are trying to achieve) and that is the root of the issue you're having.

If you download the launcher alone and replace it with this one, your problem should be fixed:

http://download01.regnumonlinegame.com/autopatch/launcher_linux64/rolauncher
(http://download01.regnumonlinegame.com/autopatch/launcher_linux64/rolauncher)

We tested in our installation of Fedora 24 and it works properly.

Sorry for the inconvenience!

[_Enio_]

Oh there you hid the link, in its own launcher folder! I was trying on live_linux64!

How did you resolve the jpeg/png dependencies?

[Adrian]

How did you resolve the jpeg/png dependencies?

Those were statically linked and GTK was complaining about it. So, now they are not linked like that anymore and rolauncher asks the system for them now. Any system that has been used a while has them and if not, you can install them. To avoid GTK having problems, better use the ones that the distro repositories provide.

The other problem I mention is the one of the other thread, about old architectures like Nocona. We'll make that available soon for testing (Well, it is on Amun right now but it's private :P )

[_Enio_]

I see, nice.


The other problem I mention is the one of the other thread, about old architectures like Nocona. We'll make that available soon for testing (Well, it is on Amun right now but it's private :P )

I was able to update the game binary from Amun, jus in case it might be of interest, the SIGILL instruction from the other thread is still there.

[enio@thinkpad live]$ cat log.txt | grep build
[09/08/2016 21:50:39] [ClientBase][client_base.cpp(343)] Client build: 39631
[enio@thinkpad live]$ objdump -d game | grep sahf
11966ba: 9e sahf
[enio@thinkpad live]$ cd ../test
[enio@thinkpad test]$ cat log.txt | grep build
[10/08/2016 10:34:04] [ClientBase][client_base.cpp(343)] Client build: 39663
[enio@thinkpad test]$ objdump -d game | grep sahf
11145ca: 9e sahf

Edit: For gcc the compiler option to not get this instruction used would be -mno-sahf.

[Adrian]

I see, nice.



I was able to update the game binary from Amun, jus in case it might be of interest, the SIGILL instruction from the other thread is still there.

[enio@thinkpad live]$ cat log.txt | grep build
[09/08/2016 21:50:39] [ClientBase][client_base.cpp(343)] Client build: 39631
[enio@thinkpad live]$ objdump -d game | grep sahf
11966ba: 9e sahf
[enio@thinkpad live]$ cd ../test
[enio@thinkpad test]$ cat log.txt | grep build
[10/08/2016 10:34:04] [ClientBase][client_base.cpp(343)] Client build: 39663
[enio@thinkpad test]$ objdump -d game | grep sahf
11145ca: 9e sahf

Edit: For gcc the compiler option to not get this instruction used would be -mno-sahf.

Test again!

[_Enio_]

Test again!

Hmm, im still getting this instruction with build 39669.


[enio@thinkpad test]$ cat log.txt | grep build
[11/08/2016 16:10:31] [ClientBase][client_base.cpp(343)] Client build: 39669
[enio@thinkpad test]$ objdump -d game | grep sahf
119671a: 9e sahf

[Adrian]

Hmm, im still getting this instruction with build 39669.


[enio@thinkpad test]$ cat log.txt | grep build
[11/08/2016 16:10:31] [ClientBase][client_base.cpp(343)] Client build: 39669
[enio@thinkpad test]$ objdump -d game | grep sahf
119671a: 9e sahf

64-bit one?

[Elanor]

First of all thanks a lot for the quick replies. I got the file from Enio's post but rolancher was still failling, this time with the error:


[siggy@alnair regnum]$ ./rolauncher
./game: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

manually installed the rpm containing libncursesw (couldn't find it in the repos i have by default). now, i don't see textures / colors https://s9.postimg.org/dprb5qedb/image.png
https://s9.postimg.org/mm239o4zj/image.png

[Adrian]

First of all thanks a lot for the quick replies. I got the file from Enio's post but rolancher was still failling, this time with the error:


Can you post the logs? (error_log.txt and log.txt)

There can be a shader failing or something similar.

[Elanor]

Can you post the logs? (error_log.txt and log.txt)

There can be a shader failing or something similar.

https://goo.gl/ShwQGd --> log.txt
https://goo.gl/zQvE3N --> error_log.txt

Someone mentioned GTK requisites. is there a list of pre requisites somewhere?
OFFTOPIC: the limits to attach files to this forum are ridiculous.

[_Enio_]

64-bit one?

Yeah, seems like.
[enio@thinkpad test]$ cat log.txt | grep build
[11/08/2016 16:10:31] [ClientBase][client_base.cpp(343)] Client build: 39669
[enio@thinkpad test]$ file game
game: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=90e30231e6ef31ede2d52c9e4055cfbe471cf0a2, stripped
[enio@thinkpad test]$ objdump -d game | grep sahf
119671a: 9e sahf
Could it come from a statically linked library?

Because it is odd, there is exactly one occurrence of this SAHF instruction, which gcc uses to optimize fmod from glibc (https://code.woboq.org/userspace/glibc/sysdeps/x86/fpu/bits/mathinline.h.html seach for fmod) while theres multiple occurrences of a seemingly unoptimized fmod.

Short excursion in the dirty deeps of assembly, (skip -> go to next bold text):
Its only occurrence:

1196711: dd 42 08 fldl 0x8(%rdx)
1196714: dd 02 fldl (%rdx)
1196716: d9 f8 fprem
1196718: df e0 fnstsw %ax
119671a: 9e sahf
119671b: 7a f9 jp 1196716 <luaopen_table@@Base+0x2956>This loads 2 floats (from adress %rdx and %rdx+8) into the FPU registers, calculates the remainder (kinda modulo) with fprem instruction, result status is now in the FPU flags, these get stored in the CPU ax register (with fnstsw %ax).

Now optimized and normal code changes.

The optimized version pushes the result status into the CPU flags with sahf. The unoptimized does the same with a test 0x4, %ah. Basically checking if the 3rd bit is one, test stores the result of the test in CPU flags.
Next follows a jp (some jump), which jumps somewhere, depending on the status in the CPU flags.
Optimization here is, that sahf seems to be much faster than test.
For the record, the unoptimized remainder calculation (Occurrs 70 times):

807950: dd 44 24 10 fldl 0x10(%rsp)
807954: dd 44 24 08 fldl 0x8(%rsp)
807958: d9 f8 fprem
80795a: df e0 fnstsw %ax
80795c: f6 c4 04 test $0x4,%ah
80795f: 75 f7 jne 807958 <_ZN6Effect11CMeshEffect15update_internalEf@@Base+0 x298>End excursion.


Since the optimization occurs only once compared to numerous unoptimized remainder calculations, i assume that theres a small part that did not get that "-mno-sahf" - either through some error in the makefiles, or by some statically linked-in code.

[Adrian]

Yeah, seems like.
[enio@thinkpad test]$ cat log.txt | grep build
[11/08/2016 16:10:31] [ClientBase][client_base.cpp(343)] Client build: 39669
[enio@thinkpad test]$ file game
game: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=90e30231e6ef31ede2d52c9e4055cfbe471cf0a2, stripped
[enio@thinkpad test]$ objdump -d game | grep sahf
119671a: 9e sahf
Could it come from a statically linked library?

Because it is odd, there is exactly one occurrence of this SAHF instruction, which gcc uses to optimize fmod from glibc (https://code.woboq.org/userspace/glibc/sysdeps/x86/fpu/bits/mathinline.h.html seach for fmod) while theres multiple occurrences of a seemingly unoptimized fmod.

Short excursion in the dirty deeps of assembly, (skip -> go to next bold text):
Its only occurrence:

1196711: dd 42 08 fldl 0x8(%rdx)
1196714: dd 02 fldl (%rdx)
1196716: d9 f8 fprem
1196718: df e0 fnstsw %ax
119671a: 9e sahf
119671b: 7a f9 jp 1196716 <luaopen_table@@Base+0x2956>This loads 2 floats (from adress %rdx and %rdx+8) into the FPU registers, calculates the remainder (kinda modulo) with fprem instruction, result status is now in the FPU flags, these get stored in the CPU ax register (with fnstsw %ax).

Now optimized and normal code changes.

The optimized version pushes the result status into the CPU flags with sahf. The unoptimized does the same with a test 0x4, %ah. Basically checking if the 3rd bit is one, test stores the result of the test in CPU flags.
Next follows a jp (some jump), which jumps somewhere, depending on the status in the CPU flags.
Optimization here is, that sahf seems to be much faster than test.
For the record, the unoptimized remainder calculation (Occurrs 70 times):

807950: dd 44 24 10 fldl 0x10(%rsp)
807954: dd 44 24 08 fldl 0x8(%rsp)
807958: d9 f8 fprem
80795a: df e0 fnstsw %ax
80795c: f6 c4 04 test $0x4,%ah
80795f: 75 f7 jne 807958 <_ZN6Effect11CMeshEffect15update_internalEf@@Base+0 x298>End excursion.


Since the optimization occurs only once compared to numerous unoptimized remainder calculations, i assume that theres a small part that did not get that "-mno-sahf" - either through some error in the makefiles, or by some statically linked-in code.

Check the other thread. I replied there!

[Adrian]

https://goo.gl/ShwQGd --> log.txt
https://goo.gl/zQvE3N --> error_log.txt

Someone mentioned GTK requisites. is there a list of pre requisites somewhere?
OFFTOPIC: the limits to attach files to this forum are ridiculous.

Could you, somehow, check the driver you were using back then with Ubuntu 16 and compare if you're using the same one?

[_Enio_]

https://goo.gl/ShwQGd --> log.txt
https://goo.gl/zQvE3N --> error_log.txt


Seems having issues with your GPU type. I'm using the same versions as you do for [11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_x11.cpp(224)] X Server vendor: The X.Org Foundation
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_x11.cpp(228)] X Server release: 1.18.4
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl.cpp(363)] XVidMode Extension version 2.2
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl.cpp(373)] Xinerama Extension version 1.1
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl.cpp(535)] OpenGL version: 3.0 Mesa 12.0.1
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_extensions_loader.cpp(312)] OpenGL Shading Language version: 1.30
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_extensions_loader.cpp(318)] Shader model 2 capable card detected


except its Fedora vendor, does that one differ from the normal one? Dont think so.

I think this needs to be fixed on NGDs end.

[Elanor]

Enio & Adrian
I'm trying to get a vm running 16.04 to compare it with what i have on my bare metal fedora 24.
In the meantime here are some specifics from my laptop:


[siggy@alnair regnum]$ uname -a
Linux alnair 4.6.4-301.fc24.x86_64 #1 SMP Tue Jul 12 11:50:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[siggy@alnair regnum]$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.0.1
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 12.0.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 12.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

[siggy@alnair regnum]$ lspci -vk
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 3977
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at e0000000 (64-bit, non-prefetchable) [size=4M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 3000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915

[Elanor]

I also see this in the logs (that i just started fresh):
error_log.txt

[siggy@alnair live]$ cat error_log.txt | grep Error | wc -l
961
[11/08/2016 15:56:13] [Texture Manager][texture_manager.cpp(212)] Error uploading texture, resource ID: 72524


log.txt

[siggy@alnair live]$ cat log.txt | grep error
0:33(42): preprocessor error: extra tokens at end of directive
error: linking with uncompiled shader

[_Enio_]

Do you have any options you can set in rolauncher options (just after login, top right) regarding render quality or anything?

Can you post the part after "OpenGL extensions:" in glxinfo? Maybe a diff to mine gives hints what your GPU doesnt like about the regnum textures.

[Elanor]

Do you have any options you can set in rolauncher options (just after login, top right) regarding render quality or anything?

Can you post the part after "OpenGL extensions:" in glxinfo? Maybe a diff to mine gives hints what your GPU doesnt like about the regnum textures.

This is the complete output of glxinfo

https://goo.gl/1BRNB8

I don't think OpenGL or the Intel driver have nothing to do with this, though. I think is either something pointing to a wrong location for the textures within the binary (ius there a reason why you guys don't provide sourceces?) or missing libraries of some sort.

[_Enio_]

I don't think OpenGL or the Intel driver have nothing to do with this, though. I think is either something pointing to a wrong location for the textures within the binary (ius there a reason why you guys don't provide sourceces?) or missing libraries of some sort.

Well, i think these are just followup errors on a bad "initialization" here, first line in your error.log:
[11/08/2016 14:29:35] [RenderizerGL][renderizer_gl_x11.cpp(353)] BadMatch (invalid parameter attributes)That RenderizerGL is a regnum module, it probably gets some values it cannot handle. But thats all just guesses.

Edit: This is the comparison of our OpenGL extensions, the left side is what i have and you do not, right side you have and i do not.
[enio@thinkpad Desktop]$ diff -y --suppress-common-lines sorted_enio.txt sorted_siggy.txt
>
> GL_AMD_performance_monitor,
GL_ARB_query_buffer_object, <
GL_ARB_robust_buffer_access_behavior, <
GL_ARB_shader_precision, <
GL_ARB_stencil_texturing, <
GL_ARB_texture_stencil8, <
GL_EXT_texture_compression_s3tc, <
> GL_INTEL_performance_query,
GL_KHR_robust_buffer_access_behavior, <
Afaik, s3tc texture compression is needed by regnum. It seems it can be enabled somehow. Check out this thread: http://askubuntu.com/questions/56379/is-there-an-easy-way-to-enable-s3tc-on-intel-graphics

Edit2: This is quite old (2011) "Using the external libtxc-dxtn library for S3TC compression. Mesa will attempt to load it if it exists, and provide full S3TC support. This is available in xorg-edgers, at least."

Edit3: [enio@thinkpad Desktop]$ locate libtxc
/usr/lib/libtxc_dxtn.so

Maybe you just need to install that one.

[Elanor]

I can see the missing intel extension


[siggy@alnair regnum]$ glxinfo | grep GL_INTEL_performance
GL_INTEL_performance_query, GL_KHR_context_flush_control, GL_KHR_debug,


and the AMD missing extension as well


[siggy@alnair regnum]$ glxinfo | grep GL_AMD_performance_monitor
GL_AMD_draw_buffers_blend, GL_AMD_performance_monitor,


Is there a list of pre requisites? just wanna make sure i have all i need.

[_Enio_]

Sorry, i was just editing my post without refreshing the page.

tl;dr from my previous post is:

Install the libtxc-dxtn library for S3TC compression support and try regnum again.

[Elanor]

I have this too:

/usr/lib64/libtxc_dxtn.so

[_Enio_]

You might also need to install "driconf" and let me quote someone else "A window appears with "Direct Rendering Settings". Go to the "Image Quality" tab. Set "Enable S3TC texture compression even if software support is not available" to yes"

[Elanor]

so i reinstalled the package libtxc_dxtn.x86_64 and now it's working properly.
Thanks a lot for the help. I was kinda surpirsed it wasn't working properly. Maybe a note about prerequisites for linux would be a good idea.

EDIT: It speaks volumes of the quality of Regnum that this is the first time i've required any kind of support to make it work since i first install it.

[_Enio_]

so i reinstalled the package libtxc_dxtn.x86_64 and now it's working properly.


This is good news. I think this is mainly an issue with distributions. Many seem to come shipping with it when installing mesa stuff.

Anyways, glad it works now.