Go Back   EQEmulator Home > EQEmulator Forums > Archives > Archive::Support > Archive::Linux Servers

Archive::Linux Servers Archive area for Linux Servers's posts that were moved here after an inactivity period of 90 days.

Reply
 
Thread Tools Display Modes
  #1  
Old 04-24-2002, 02:18 PM
discore
Fire Beetle
 
Join Date: Apr 2002
Posts: 1
Default zone segfaulting.

Hello. I am attempting to run an EQEmu server off of a Debian 2.4.17 machine.

Firstly I had a problem since my machine is multihomed and it wasn't getting the correct interface. The_Coder's patch fixed that nicely.

Now I can connect to the server, and create a character, but when I attempt to login the zone process segfaults and I see "Zone not available" in EQ.

Here is straced output of the zone binary:
<zone loads, no errors, and goes to sleep>
nanosleep({0, 1000000}, NULL) = 0
gettimeofday({1019699449, 383551}, NULL) = 0
nanosleep({0, 1000000}, Map: Maps\halas.map not found.
NULL) = 0
<insert less than a second of nanosleep() spam here>
nanosleep({0, 1000000}, NULL) = 0
gettimeofday({1019699449, 837093}, NULL) = 0
nanosleep({0, 1000000}, 0) = -1 EINTR (Interrupted system call)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

It happens right after it tries to load the nonexistant .map file. I have read that these files aren't meant to exist yet, so I assume that is supposed to happen. Looking at the Map.cpp source, it seems to make a clean enough exit if the map isn't found. I can't figure out why they would segfault instead.

Also, the world binary complains a bit:
Removing zoneserver from ip:127.0.0.1 port:51429 (166.70.x.x:799
Zoneserver send() failed, assumed disconnect: #7 127.0.0.1:51427 (166.70.x.x:7996)
send_socket=15, Status: -1, Errorcode: Broken pipe
Removing zoneserver from ip:127.0.0.1 port:51427 (166.70.x.x:7996)
Zoneserver send() failed, assumed disconnect: #8 127.0.0.1:51428 (166.70.x.x:7997)
send_socket=16, Status: -1, Errorcode: Broken pipe


Just to check, I assume this shell script will work fine for starting zones:
(discore@chalkdust /usr/local/eqemu)% cat startzones.sh
./zone . <eth0's ip> 7995 127.0.0.1 &
./zone . <eth0's ip> 7996 127.0.0.1 &
./zone . <eth0's ip> 7997 127.0.0.1 &
./zone . <eth0's ip> 7998 127.0.0.1 &
./zone . <eth0's ip> 7999 127.0.0.1 &

Like I said, all 5 load without any errors. I have tried multiple things in the 4th field, 'localhost', '<eth0's ip>', and such. /etc/hosts has all the proper info as well. <eth0's ip> also matches the worldaddress= in the .ini file. I removed the account= and password= lines from the .ini, as per The_Coder's instructions on the NAT thread. But I doubt that's relevant..

Any ideas?
Reply With Quote
  #2  
Old 04-27-2002, 08:16 AM
theCoder
Sarnak
 
Join Date: Jan 2002
Posts: 90
Default

I can't tell offhand what the problem is (I haven't had this problem, but I haven't tested 0.3.1 extensively -- finals coming up and all...)

Your world log is probably just reflecting the fact that the world server noticed the zone server had disappeared mysteriously (segfaulted) and was removing it from it's list of zone servers.

The fourth parameter to zone should only affect how zone connects to the world server, so it can be anything that can resolve to the host world is running on (localhost, 127.0.0.1, public IP, internal IP, etc). The NAT patch binds to the interface specified in the second parameter (just checked to make sure).

I'm not sure what exactly is going on from the strace. I looks like there's a Sleep() call that is failing. Really, it's usleep which is called unser the Linux build (see common/unix.cpp), which I guess calls nanosleep(?), which is failing. AFAIK, there are no direct calls in the code to either nanosleep or usleep (except through Sleep in unix.cpp). Based on the parameters to the call of nanosleep, it looks like the call was Sleep(1). There are 5 calls of Sleep(1) in zone/* and 2 in common/* (from grep). I'd bet that the problem is around one of them. Perhaps some debug printf's (or cout as seems to be the style in the emu) would be helpful in determining where it's happening. I know there are several debug print outs already in the code, but you have to turn the debug level up (I think at least one is debug_level in common/EQPacketManager.cpp). However, I'm not sure that those would help here since they seem to be debugs for the networking code.

Also, are you running 0.3.1, or the patch 0.3.1.1? Or another older version?
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 07:43 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3