CentOS 7 x64 Segmentation fault

[Lanman.CZ 10]

Hello,

I have a problem starting the Linux dedicated server on my CentOS 7 x64 box. I followed the instructions from here :

https://community.bistudio.com/wiki/Arma_3_Dedicated_Server

No problem with steam installation and arma3 download as far as I can tell. All seems to be ok, the game installed fine, validation/update is ok however whenever I try to actually start the server I get :

[steam@server arma3]$ ./arma3server -name=server -world=empty

Segmentation fault (core dumped)

[steam@server arma3]$

The core file created has ~4GB.

My ulimits for this user are unlimited.

Linux server 3.10.0-123.9.2.el7.x86_64 #1 SMP Tue Oct 28 18:05:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The server is Intel Core 2 Quad Q9400 with 8GB RAM. OS is up-to-date, no other crazy stuff is running on the server just samba, proftpd, teamspeak3 and the server is idling, SElinux is off, firewalld is enabled (ports 2302,2303,2304,2305,2344,2345 opened for tcp & udp, forwarding enabled on router as well).

Any ideas pls ? Does the dedicated server create any log file that I might check out for clues ? I didn't find any.

Edited November 6, 2014 by Lanman.CZ

[Lanman.CZ 10]

I tried to use gdb to give me some idea what's wrong unfortunately I'm not such good programmer to figure out what's going on. The backtrace looks like this, if anyone knows what that means :

(gdb) run

Starting program: /home/steam/steamcmd/arma3/./arma3server

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

Missing separate debuginfo for /home/steam/steamcmd/arma3/libsteam_api.so

Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/90/9ac6ec0b411101b923ba8a89747db9763257f8.debug

[New Thread 0xf7fdab40 (LWP 21476)]

Program received signal SIGSEGV, Segmentation fault.

0x00000000 in ?? ()

Missing separate debuginfos, use: debuginfo-install glibc-2.17-55.el7_0.1.i686 libgcc-4.8.2-16.2.el7_0.i686 libstdc++-4.8.2-16.2.el7_0.i686

(gdb) bt

#0 0x00000000 in ?? ()

#1 0x08137e27 in ?? ()

#2 0x081391f7 in ?? ()

#3 0x0813b695 in ?? ()

#4 0x0813bb3b in ?? ()

#5 0x0813c751 in ?? ()

#6 0x081c28ee in ?? ()

#7 0x081bf80b in ?? ()

#8 0x081a07ba in ?? ()

#9 0x081a08d6 in ?? ()

#10 0x08dcf256 in ?? ()

#11 0x08ddb4d7 in ?? ()

#12 0x080b4111 in ?? ()

#13 0xf7ca1933 in __libc_start_main () from /lib/libc.so.6

#14 0x080dfd75 in ?? ()

(gdb)

[Lanman.CZ 10]

Hmm, so I installed Ubuntu 12 x86 into virtual box and there the dedicated server works but still crashes with segmentation fault under CentOS 7 x64. But at least I got it working that way.

Edited November 6, 2014 by Lanman.CZ

[dr death jm 117]

Hmm, so I installed Ubuntu 12 x86 into virtual box and there the dedicated server works but still crashes with segmentation fault under CentOS 7 x64. But at least I got it working that way.

i can drop some files in drop box if you like and you can see if its somthing you did wrong?

[Lanman.CZ 10]

i can drop some files in drop box if you like and you can see if its somthing you did wrong?

Nah, thanks. I don't think I did anything wrong. Under Ubuntu 12 x86 it works fine but under CentOS 7 x64 it does not. It would be nicer if it worked directly under my server OS which is the CentOS so I didn't have to run it in virtualbox but I'm still happy with it. At least it works this way.

[mahuja 12]

Using virtualbox may negatively impact performance, though I don't know by how much. (It may even be unmeasurable, but I wouldn't bet on it.)

And it's one more OS to support/update.

I'm fairly new to linux development myself, but I've been in depth the last several weeks at work.

I tried to use gdb to give me some idea what's wrong unfortunately I'm not such good programmer to figure out what's going on. The backtrace looks like this, if anyone knows what that means :

Program received signal SIGSEGV, Segmentation fault.

0x00000000 in ?? ()

Missing separate debuginfos, use: debuginfo-install glibc-2.17-55.el7_0.1.i686 libgcc-4.8.2-16.2.el7_0.i686 libstdc++-4.8.2-16.2.el7_0.i686

(gdb) bt

#0 0x00000000 in ?? ()

#1 0x08137e27 in ?? ()

... bunch of 0x08

#12 0x080b4111 in ?? ()

#13 0xf7ca1933 in __libc_start_main () from /lib/libc.so.6

#14 0x080dfd75 in ?? ()

(gdb)

Because the action was not done, I'm forced to do a bit of guessing. Something that could be more useful is to get a memory mapping listing (of code areas) that maps memory space to what files that code resides in, so as to check against all those addresses, but I have no idea of how to produce that in GDB.

At #12, we enter the game's main() function, and then a bunch of calls are done in the same area of memory, meaning it's probably (here's my guessing) all inside the game's code, eventually ending at #2 which tries to call a function null pointer, leading to #1. Everything done up to that point succeeded, which was probably a lot if the dump measures "~4GB".

Page 0 is always (as far as we're concerned) nonexistent, such that this case crashes with a SIGSEGV rather than let it continue when there's no way it'll be in a valid state again.

Function null pointers tend to appear when trying to use a non-existent function from some .so file. (Especially since it's system dependent; it does work in one case.)

.so "Shared object" is the linux equivalent of windows' .dll "Dynamic link library".

I don't think arma3server does 'manual work' with .so files except for extensions, so most likely this is a result of a library version mismatch.

The server was compiled with one version of some library, and is here served with (probably) an older version of that same library, that does not have that function.

(At work, I'm currently struggling with the reverse problem, but once I get it right I can be pretty sure it will not crash from this at runtime. Which is kind of essential for an oracle db.)

To continue debugging this issue do ldd arma3server and compare the outputs for the working and nonworking version.

In particular you're looking for significant version differences in libraries. (What counts as "significant" depends on each library.)

Libraries that only exist in one but not the other is probably not an issue - then it wouldn't start at all because it was missing.

Edited November 7, 2014 by MaHuJa

[Lanman.CZ 10]

Hello,

thanks for reply. The performance impact of this setup is negligible so I run it like that under virtual ubutuntu and it works fine.

As for why it does not work under the centos I dont know. Looks to me like some incompatibility with new kernel/library version probably. But since it works under the old ubuntu I didn't investigate further.

[astrell 3]

Did run arma3server in vm's of Debian, Ubuntu and Windows server 2008 in exsi without getting some major fps drops or "had the feeling" to have fewer performance. If it's working I guess let it run.

[byteslam 10]

Did run arma3server in vm's of Debian, Ubuntu and Windows server 2008 in exsi without getting some major fps drops or "had the feeling" to have fewer performance. If it's working I guess let it run.

One question, in VM means always as Windows instance or did you also run Linux (steamcmd checked out) servers? and if, did the server appear as green in the browser?

[astrell 3]

Windows and Linux the same time, if you selected the ports correctly than everything good and fine. Green, good ping.