1.90f linux and segmentation fault

[Lithorus 0]

I've been trying to setup a dedicated operation flashpoint server on my debian box but only with this result :

22:20:08 Dedicated server created

Segmentation fault

I haven't had any problems with other linux dedicated servers (eg. ut2003 and bf1942) and I have no idea why it won't run.

Btw. I run testing on the debian box.

Also is there a way to make extensive logging, to help figure out what it's trying to do and what my causing it to crash?

[benu 1]

Try checking with strace what exactly is the problem...

[Lithorus 0]

Oh, thx. Just the program I was looking for.

In the meantime I've tried running it on another box running knoppix(based on debian) with the excact same result

[Lithorus 0]

I tried tracing it and it seems to crash right after loading some libc6 libraries. Is the server compiled with some funky gcc and will it ONLY run on redhat?

[benu 1]

I had it running on redhat and gentoo with different libc, so that should not be the problem. Sorry i can't help you more

[Lithorus 0]

Update :

Recently there was a huge update of the testing(sarge) dist of debian and with a new libc6. I tried running the flashpoint server again and now it works fine. So it seems it does require a minimum version of libc6. Would be nice if they included a little more stats on the requirements.

[Hellek 0]

Yep, I also think that a bit more info would be cool, I am currently running a dedicated server (of course the latest release, not 1.90f) on RedHat8, no problems. Now I got access to a faster machine which is Running with RedHat9 and it does not work.

I saw that RH8 uses glibc2.2 and RH9 uses glibc2.3, maybe this causes the problem?

(Assuming that I am right and this is the reason why it does not work on my RH9 comp): It would be really nice if you wou would compile it both for glibc2.2 and 2.3.

PS: Is anybody running the Linux Ded. Server on RH9 without problems? (then I would know that it is not the glibc)

[benu 1]

Try running the server with strace to see what's going wrong. Or try to unset LANG (or at least unset UTF-8)...

[Hellek 0]

[david@image ~/ofp]$ strace -o strace.log ./server -config=server.cfg

23:21:17 Dedicated server created, memory used: 8308 KB

Server creation failed : 2302

My strace.log is 8.3 megabytes big so it is not helpful as I don't know what to look for.

The fact that it says "Server createn failed : 2302" is a bit interesting as the error message includes the port it should run on. But I can open this port, I tried that and netstat -al also does not list the port as already open.

What does "unset LANG or UTF-8 mean"? Is it deleting environment variables?

$LANG is set to en_US.UTF-8 on both systems (on the RH8 one where OFP is working and on the RH9 one where it is not working)

[benu 1]

I had some programs which wouldn't start when UTF was set, this seems not to be your problem though. The "port 2302" normally means something is not correct with your network setup, check your /etc/hosts, resolv.conf, route, ifconfig, etc. Use the search function for more about this topic.

[Hellek 0]

Hmm, resolving works on both, also route and ifconfig did not show anything special and other programs which use networking do not have any problems on the system.

I just looked through the forums and found out that adding

reportingIP="";

to the flashpoint.cfg might help and it indeed does. Now I only have to figure out why ...

PS: FYI: It prevents OFP from reporting to gamespy so the drawback is that nobody will find the server

[Hellek 0]

now it does not work any more at all and i did not change anything. it is so weird :-(

[Hellek 0]

some differences which I now found with strace:

on system image (not working)

connect(92, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)

open("/lib/tls/libc.so.6", O_RDONLY) = 92

on system cipher (working)

connect(92, {sin_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)

open("/lib/i686/libc.so.6", O_RDONLY) = 92

also:

image:

munmap(0x5d27a000, 127526) = 0

munmap(0x5d38d000, 47068) = 0

munmap(0x5d399000, 1261416) = 0

munmap(0x5d4cd000, 90100) = 0

open("/etc/ld.so.cache", O_RDONLY) = 92

cipher:

munmap(0x5d27a000, 110992) = 0

open("/etc/host.conf", O_RDONLY) = 92

fstat64(92, {st_mode=S_IFREG|0644, st_size=17, ...}) = 0

old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5d27a000

read(92, "order hosts,bind\n", 4096) = 17

read(92, "", 4096) = 0

close(92) = 0

munmap(0x5d27a000, 4096) = 0

brk(0) = 0xa139000

brk(0xa13a000) = 0xa13a000

brk(0) = 0xa13a000

open("/etc/hosts", O_RDONLY) = 92

fcntl64(92, F_GETFD) = 0

fcntl64(92, F_SETFD, FD_CLOEXEC) = 0

fstat64(92, {st_mode=S_IFREG|0644, st_size=147, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5d27a000

read(92, "# Do not remove the following li"..., 4096) = 147

read(92, "", 4096) = 0

close(92) = 0

munmap(0x5d27a000, 4096) = 0

open("/etc/ld.so.cache", O_RDONLY) = 92

so it somehow left out opening /etc/host.conf

Also on cipher there are entries like

net_addr("<ip adress of the host edited out>")}}, 16) = 92

which are not on image

So it is really very, very weird, all other programs work without any problems and also resolving works without probs

Also on both systems I have lines like

uname({sys="Linux", node="image.domain.edited.out", ...}) = 0

uname({sys="Linux", node="cipher.domain.edited.out", ...}) = 0

so it at least manages to find out the actual hostname on both systems.

PS: Another thing which I don't understand is that already the first line is different:

Cipher: execve("./server", ["./server", "-config=server.cfg"], [/* 29 vars */]) = 0

Image: execve("./server", ["./server", "-config=server.cfg"], [/* 30 vars */]) = 0

[benu 1]

On my server host.conf looks like this:

-rw-r--r-- 1 root root 17 Jul 23 2000 host.conf

The content is:

order hosts,bind

But on another box i hosted a server on there was no host.conf at all. So i don't think that this file is the problem. But "order hosts,bind" looks like a name resolving issue, so you should check your /etc/hosts, /etc/resolv.conf and maybe your /etc/nsswitch.conf and the hostname command.

[Hellek 0]

no, did not find anything special in those files, and they are of course all -rw-r--r-- as usual

hostname also worked as supposed.

[Lobanak 0]

If you have problems with server creation, it can be hostname, IP number and missing entry in /etc/hosts.

If you have IP "192.xxx.xxx.1" and hostname "ofpserver" with domain "my.dom" you should have following entry in /etc/hosts:

Quote[/b] ]192.xxx.xxx.1 ofpserver.my.dom ofpserver

check with 'ifconfig', 'hostname' and other things for the right settings. Had the problem several times.

I also noticed on my gentoo box, that the server works with glibc-3.2.1 but not with glibc-3.2.2 and glibc-3.2.3. Searched a lot till I come to the point that the only thing could be the glibc, cause I have updated this.

Try to use the 1.91c server. It works well on our server. Also 1.92 should come out soon.

Greets

[CiA]Lobanak

[Hellek 0]

yeah, I am using 1.91c, the topic name is missleading because I did not create this topic.

I already checked /etc/hosts, hostname, ifconfig, etc., all seem to be right:

127.0.0.1 localhost.localdomain localhost

141.201.7.198 image.mat.sbg.ac.at image

[david@image ~/ofp]$ hostname

image.mat.sbg.ac.at

ifconfig of course also showed me 141.201.7.198 with subnetmask 255.255.255.0 on interface eth0 with "UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1"

all the nameservers in /etc/resolv.conf are of course working, everything is alright.

Concerning the glibc: The system where it is working is RH8 (which means glibc 2.2), the system where it is not working is RH9 (glibc 2.3). Did you manage to make the server run with glibc 2.3?

[Lobanak 0]

ah... now I know what the problem is. RH 9 uses a new form of thread handling (as I know) and so all or most programs must be recompiled that they use the new thread handling. As the ofp server is not compiled in such way, it's not possible to run the ofp server on RH 9. I tried it at the time RH 9 came out, but had no luck.

Try using another RH version or another linux distribution.

Greets

[CiA]Lobanak

[Hellek 0]

Unfortunately I can't downgrade to RH8, have to keep RH9.

So I have to stick with the slower server which has RH8 installed

PS: Tried 1.92 Beta, also did not work (not really a surprise)

[suma 8]

We are running our server on RedHat 9. As far as I know, the only thing you need to do is to to start "nscd" deamon. I will not tell you what this demon is and why it is required on RH9 and not on RH7, as this is beyond my linux knowledge.

You can find some relevant info in Pb with dedicated linux server 1.91c

[Hellek 0]

Thanks, it works now. Sorry that I did not find the thread myself.

[Adammo 0]

Suma,

I'm running RH9 with nscd with dedicated server 1.92 beta.

Here is a log file while running the game:

18:32:45 Roles assigned

18:32:45 Reading mission ...

18:33:05 Mission read

18:33:06 Admin [iCM]-Moore logged in.

18:34:07 Game started

18:48:29 Player [iCM]-Moore disconnected

18:48:29 Admin [iCM]-Moore logged out.

18:51:55 Player Cpt Moore connecting

18:52:01 Player Cpt Moore connected (id=195)

Segmentation fault

[root@ ofp]#

The game is running and then all of a sudden I get a Seg. fault error and it crashes.

This happens at random times during the map and I haven't be able to pinpoint what is causing it during the mission.

-Adammo

[Adammo 0]

I'm not sure that the nscd has anything to do with the segmentation fault... on the other hand maybe the service is stopping in mid game and the server crashes... I guess the best thing to do is just to resintalled Redhad 8 and run it there instead...

I run the ncsd and still have the fault crash

Has anyone had this segmentation fault error happen in Redhat 8?

-Adammo

[benu 1]

I just checked: i don't use nscd on my gentoo 1.4 box and ofp works there. Don't know if this is any help for your problem though.

[Adammo 0]

I installed redhat 8 and I still get the segmentation fault...

....

-Adammo