1.90f linux and segmentation fault

[Hellek]

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]

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

[Hellek]

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&#39;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]

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&#39;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]

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]

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 &#39;ifconfig&#39;, &#39;hostname&#39; 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]

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]&#036; 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]

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&#39;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]

Unfortunately I can&#39;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]

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