My server doesn't like SoF clients

[prickle]

I finally purchased a copy of SoF to play with, and my Eqemu server which seemed to be working fine with my Titanium client crashes every time I try to log in with my SoF client. I copied the new spells_us.txt and spells_en.txt to the server's directory. I get to the character select screen just fine, but when I click "Enter World" the server logs tell me that the server detects the SoF client properly and then the zone I'm entering crashes.

I've recompiled from scratch so many times and even tried starting over with a fresh database, but so far, nothing I've tried will allow me to connect to my server with an SoF client.

I've installed svns of the quests and maps, but it didn't help.

I can connect to public Eqemu servers with my SoF client, but no matter which zone my character is in, my SoF client crashes the zone server.

I've been through the Debian Linux setup guide several times, but it doesn't mention anything SoF specific.

I'm stuck confused as to why my SoF client is doing this to my Eqemu server, but connections to the public Eqemu servers without any problems.

Anyone have any ideas what I'm newbing out on to make my zone server always crash when a SoF client connects to it?

[trevius]

What source revision are you running on your server? Also, did you make sure to copy your .conf file over for the new SoF updates to it? If your client connects fine on other servers, then it must be something specific to your server. Have you tried making a new character and seeing if you can log all of the way in and stable with that? If so, maybe something you are doing or have set on your main char is the problem. Like, maybe your level is too high, or something custom is on him that SoF isn't liking.

[prickle]

Thanks for the reply. I'll try to answer your questions as best I can:

What source revision are you running on your server?

I'm currently running svn Rev. 1048... I started having problems with Rev 1038, but decided to upgrade incase it was the version I was running.

Also, did you make sure to copy your .conf file over for the new SoF updates to it?

If you're referring to the patch_SoF.conf file, yes, it is in the server directory. The server identifies the packet stream properly and the logs say it applies the patch successfully, but when a SoF client connects to the zone server it crashes.

If your client connects fine on other servers, then it must be something specific to your server.

I agree, that's why I'm asking in the Linux Server Support forum and not in the General Support forum.

Have you tried making a new character and seeing if you can log all of the way in and stable with that? If so, maybe something you are doing or have set on your main char is the problem. Like, maybe your level is too high, or something custom is on him that SoF isn't liking.

Maybe, I haven't tried that yet. However, I don't think it'll be a level thing honestly, because my toon is only level 55.

To further my own research into my problems, I had a friend helping me from a Windows XP system and we did the following:
-Copied my EqEmu server directory to his Windows XP
-Replaced the Linux binaries with Windows binaries
-Tweaked the Windows EqEmu config to make it use the Linux MySQL server
-Tweaked the Windows EqEmu config to use the database we've been playing on

Once we had the Windows EqEmu server running and using the same database that we've been using with the Linux server, we logged in and found that both of our SoF clients were able to connect without any problems.

The testing we did last night lead me to the following:

1) There's something severely wrong with my Linux compiles lately.
2) My issues are NOT database related.

I originally started having problems with bot zoning after I upgrade Ubuntu 9.04 to 9.10 (apt-get upgrade that went 8.04>8.10>9.04>9.10). Since I was having EqEmu problems on Ubbie 9.10 that I wasn't having with Ubbie 9.04, I reverted to Ubbie 9.04 by doing a fresh install. The compiles I tested out last night after starting this thread were severely borked, my Titanium client was causing the zone server to crash if I zoned, but logging into a zone was fine, and I noticed that I was getting ~weird~ zoning messages in the server error logs (e.g. zoning from Dawnshroud to Griegs End would give me server logs saying it was sending me to Misty Moutains)...

So, at this point, I'm convinced that there's something in the newer Ubuntu C libs, C++ libs, gcc, or g++ packages that just isn't agreeing with EqEmu. I haven't tried changing out my gcc to 4.1 yet, and I don't think I will even bother with trying that.

Since I have today off from work, I'm going to revert my Linux box back to a fresh Ubuntu 8.04 LTS install and go from there...

Also, all this compiling and hand editing the makefiles, is giving me some motivation to try and come up with a ./configure script to help make compiling on Linux a bit easier...

[gaeorn]

Originally Posted by prickle

... when I click "Enter World" the server logs tell me that the server detects the SoF client properly and then the zone I'm entering crashes.

I'll bet you are running 64bit. I had this problem with a 64bit system and tracked it down to a gcc optimization bug and stringstreams. The SoF code uses stringstreams and since the default makefile includes the -O flag, i'm sure you are compiling optimized. Since removing -O from the makefile will slow the server significantly, you should instead modify the makefile so it will compile the one object file without the -O. The following patch will do so for you.

Index: zone/makefile
===================================================================
--- zone/makefile       (revision 1048)
+++ zone/makefile       (working copy)
@@ -18,6 +18,7 @@
 PERL_LIB=$(shell perl -MExtUtils::Embed -e ldopts)
 DFLAGS+=-DEMBPERL -DEMBPERL_PLUGIN -DHAS_UNION_SEMUN
 WFLAGS=-fpermissive -Wall -Wuninitialized -Wwrite-strings -Wcast-qual -Wno-deprecated  -Wcomment -Wcast-align
+SOFCOPTS=$(WFLAGS) -g -pthread -pipe -D_GNU_SOURCE -DINVERSEXY -DFX -DZONE $(DFLAGS) $(MYSQL_FLAGS) $(PERL_FLAGS)
 COPTS=$(WFLAGS) -O -g -march=i686 -pthread -pipe -D_GNU_SOURCE -DINVERSEXY -DFX -DZONE $(DFLAGS) $(MYSQL_FLAGS) $(PERL_FLAGS)
 LINKOPTS=$(COPTS) -rdynamic -L. -lstdc++ -ldl $(MYSQL_LIB) $(PERL_LIB)

@@ -27,6 +28,9 @@

 include makefile.common

+../common/patches/SoF.o: ../common/patches/SoF.cpp
+        $(CC) $(NOLINK) $(SOFCOPTS) $< $(OUT)$@
+
 .depend depend:
        for f in $(SF); \
        do \

[prickle]

Excellent! I'll give this a try!

[prickle]

this worked out perfectly! Zoning takes a couple of seconds longer, but I can deal with it as long as I can play with my SoF client!

[prickle]

Ok, a little update on this issue I had...

The changes listd above worked great on my server with my SoF client UNTIL I recompiled with bots. Once I added -DBOTS to world/makefile and zone/makefile and added bot.o to zone/makefile.common, my server started rejecting SoF clients again, AND the bots weren't zoning with Titanium clients....

SO, to make bot zoning, and SoF play nice with bots enabled I did the following:

edited world/makefile:

removed -O and -march=athlon64 from the COPTS line. So my current COPTS= line looks like:

COPTS=$(WFLAGS) -g -pthread -pipe -I../common/SocketLib \
 -DFX -D_GNU_SOURCE -DINVERSEXY -DWORLD $(DFLAGS) $(MYSQL_FLAGS) $(PERL_FLAGS)

Edited my zone/makefile:

Again edited my COPTS= line to remove ALL optimizations. This is the COPTS= line from my zone/makefile:

COPTS=$(WFLAGS) -g -pthread -pipe -D_GNU_SOURCE -DINVERSEXY -DFX -DZONE $(DFLAGS) $(MYSQL_FLAGS) $(PERL_FLAGS)

I tried it with just the changes suggested above, but with bots it didn't work for me. I then tried it with the optimizations stripped out of the zone/makefile, but it still wouldn't play nice with SoF. I had to strip optimizations out of bot the world and the zone makefile to make it play nice with SoF while bots are enabled.

Incidentally, this also fixed a bot zoning problem I'd been having. With the optimizations turned on the bot zoning code would get to line 3638 of the bot.cpp file and then bomb out. After turning the optimizations off it works fine for me.

In case it interests anyone this is the line in the bots.cpp that bombs out with Titanium clients and optimizations turned on for my server:

std::list<uint32> ActiveBots = Bot::GetGroupedBotsByGroupId(botOwner->GetGroup()->GetID(), &errorMessage);

I know environment plays as much of a role as anything else when it comes to compiling code. So, if it helps anyone else, the following are my server's stats:

Ubuntu 9.10 AMD64 Desktop
AMD Anthlon64 x2
4GB DDR2 RAM
AMD AM780G Chipset

GCC:

home:~$ gcc --version
gcc (GCC) 4.1.3 20080704 (prerelease) (Ubuntu 4.1.2-27ubuntu1)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Prior to upgrading to Ubuntu 9.10, I was compiling with gcc-4.3.3. The builds with default optimizations (well, I had to change -march=i686 to -march=athlon64 to compile) on that version seemed to be ok on Ubuntu 9.04. Once I upgraded to Ubuntu 9.10, the bots stopped zoning (with the binaries that I made on 9.04), and SoF clients wouldn't get into the world (never got to try SoF while I was on 9.04 so I don't know if that worked).

-O optimizations are usually considered "the safe" optimization, and I've seen most people recommend using -O2. However, I'm not sure why, but they have an adverse effect on EqEmu on my particular system (or maybe limited to AMD hardware?).

Incidentally, when the -march= optimization is removed the compiler automatically selects -mtune=generic for the CPU optimization.

ANYWAY! Thanks for tgetting me pointed in the right direction!

[gaeorn]

Originally Posted by prickle

Ok, a little update on this issue I had...

The changes listd above worked great on my server with my SoF client UNTIL I recompiled with bots. Once I added -DBOTS to world/makefile and zone/makefile and added bot.o to zone/makefile.common, my server started rejecting SoF clients again, AND the bots weren't zoning with Titanium clients....

The new bot code includes stringstreams, so would have the same problems as the SoF code.

[gaeorn]

Also, I've not tested it, but it's possible it is a conflict between -g and -O. It's hard for a compiler to do debugging and optimization so perhaps removing the debugging (-g) would allow the optimization.

[prickle]

interesting. I'll have to play around with those on my next day off from work to see what i can and can't do with those flags to get a working server going... thanks for the additional informaiton

[Teloriose]

How would one go about fixing this on client side? I have a bit of experience coding but have never messed with EQ.

[prickle]

eh? is your SoF client crashing? If so, that's an entirely different issue...