EQEmulator Forums - Server is up and running, but there's no inventory

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Support::Linux Servers (https://www.eqemulator.org/forums/forumdisplay.php?f=588)

- - Server is up and running, but there's no inventory (https://www.eqemulator.org/forums/showthread.php?t=31909)

Server is up and running, but there's no inventory

Greetings,

I have compiled and gotten running two servers on two different OSes, and both are experiencing the exact same problem: I can log in, create a character, interact with NPC's, and wander about the world without any issues. However, I have no inventory.

When I start up my server, I see a message about items loading:

Code:

[Status] Loading items from database: count=83375

Everything looks ok, more debug messages go by, nothing alarming...

The world log captures:

Code:

41544 [08.23. - 15:38:31] Starting Log: logs/eqemu_world.log

41544 [08.23. - 15:38:31] Using database 'eqemu' at localhost:3306

41544 [08.23. - 15:38:31] libEMuShareMem.so loaded

41544 [08.23. - 15:38:31] Loading items from database: count=83375

Everything looks good. I am able to log in, create my character, and start running around the world, except my inventory is empty.

Digging through the logs, I find in files logs/zone-dynamic_0n (where 1 <= n <= 5):

Code:

[Debug] Starting Log: logs/eqemu_debug_zone.log

[Debug] [ZONE__INIT] Loading server configuration..

[Debug] [ZONE__INIT] Warning: Unable to read log.ini

[Debug] [ZONE__INIT] Connecting to MySQL...

[Status] Starting Log: logs/eqemu_zone.log

[Status] Using database 'eqemu' at localhost:3306

[Debug] [ZONE__INIT] CURRENT_ZONE_VERSION: EQEmulator 0.8.0

[Debug] [COMMON__THREADS] Starting DBAsyncLoop with thread ID 26223568

[Debug] [ZONE__INIT] Warning: Unable to read ./log.ini

[Debug] [ZONE__INIT] Mapping Incoming Opcodes

[Debug] [ZONE__INIT] Loading Variables

[Debug] [ZONE__INIT] Loading zone names

[Debug] [ZONE__INIT] Loading items

[Error] Starting Log: logs/eqemu_error_zone.log

[Error] LoadEMuShareMemDLL::Load() failed to attach Items.GetItem

[Debug] [ZONE__INIT_ERR] Loading items FAILED!

[Debug] [ZONE__INIT] Failed.  But ignoring error and going on...

[Debug] [ZONE__INIT] Loading npc faction lists

[Status] libEMuShareMem.so loaded

failed to get 0-length shared mem: Function not implemented

shmat failed! Function not implemented

[Warning] Could not attach to shared memory proceeding on isolated memory (share

_id <= 0)

[Status] Loading NPC Faction Lists from database...

[Debug] [ZONE__INIT] Loading loot tables

failed to get 0-length shared mem: Function not implemented

shmat failed! Function not implemented

[Warning] Could not attach to shared memory proceeding on isolated memory (share_id <= 0)

[Status] Loading Loot tables from database...

[Debug] [ZONE__INIT] Loading skill caps

failed to get 0-length shared mem: Function not implemented

shmat failed! Function not implemented

[Warning] Could not attach to shared memory proceeding on isolated memory (share_id <= 0)

[Status] Loading skill caps from database...

[Debug] [ZONE__INIT] Loading spells

failed to get 0-length shared mem: Function not implemented

shmat failed! Function not implemented

[Warning] Could not attach to shared memory proceeding on isolated memory (share_id <= 0)

[Debug] [ZONE__INIT] Loading guilds

[Debug] [ZONE__INIT] Loading factions

[Debug] [ZONE__INIT] Loading titles

[Debug] [ZONE__INIT] Loading AA effects

[Debug] [ZONE__INIT] Loading tributes

[Debug] [ZONE__INIT] Loading corpse timers

[Debug] [ZONE__INIT] Loading commands

[Debug] command_init(): - Command 'acceptrules' set to access level 0.

...

[Debug] command_init(): - Command 'zuwcoords' set to access level 80.

[Debug] [ZONE__INIT] 238 commands loaded

[Debug] [ZONE__INIT] Loaded default rule set 'default'

[Debug] [ZONE__INIT] Loading Tasks

[Debug] [ZONE__INIT] Loading embedded perl XS

[Debug] [ZONE__INIT] Loading quests

[Quest] Starting Log: logs/eqemu_quest_zone.log

[Quest] Tying perl output to eqemu logs

[Quest] Creating EQEmuIO=HASH(0x806818888)

[Quest] Creating EQEmuIO=HASH(0x806818ee8)

[Quest] Loading perlemb plugins.

[Quest] Unable to read perl file 'plugin.pl'

[Quest] Loading perl commands...

[Quest] Unable to read perl file 'commands.pl'

I suspect something may not have compiled right, based on the highlighted error, but I can't seem to find anything that jumps out at me in the file common/SharedLibrary.cpp where the highlighted error above seems to be stemming from.

I built the server binaries from source from August 12:

Code:

svn checkout http://projecteqemu.googlecode.com/svn/trunk/ eqemu

The database I have is peqdb_rev1589.sql, obtained from http://www.projecteq.net/, which as far as I can tell is the latest and the one that should go with the current source.

Any thoughts on where I might be going wrong?

Thanks for any help.

What OSes have you been using?

Ubuntu 10.04.1 and FreeBSD 7.2-p8 jail, both AMD 64-bit.
Sometimes Zones core-dumps on the Ubuntu system.
Aside from the no-items issue, it runs rock-solid on the FreeBSD system.

Ah, 64 bit. As far as I know, everything doesn't work perfectly with 64 bit eqemu yet. There may be some other people who have posted about their experiences here.

I've been running on FreeBSD amd64 in a jail(7.x-8.x), for quite a while without any noticable issues.
Are you using erde's autobuild scripts here? I'm assuming since you got it to compile you are at least using the freebsd patch included there.

You will need this additional patch as well:

Code:

--- common/SharedLibrary.cpp    2009-10-19 14:58:05.000000000 +0000

+++ common/SharedLibrary.cpp.new        2009-10-19 15:44:46.000000000 +0000

@@ -83,10 +83,10 @@

                return(NULL);

        

        void *r = GetProcAddress(hDLL, name);

-

-       if(GetError() != NULL)

-               r = NULL;

-

+       if ( r == NULL ) {

+               const char *load_error = GetError();

+               fprintf(stderr, "[Error] Shared Library GetSym: '%s' failed.  Error=%s\n", name, load_error?load_error:"Null Return, no error");

+       }

        return(r);

 }

You will also need a line like this in your rc.conf file of the system hosting your jails:

Code:

jail_sysvipc_allow="YES"

Thanks, amraist!
No, my Google-Fu and Search-Fu were weak, as all I came across were people lamenting how EQEmu didn't work in FreeBSD from a few years ago. And that just wouldn't do!
I did not previously find erde's scripts or patches, I used gmake with the default makefiles, which seemed to work with some slight tweaking:

Code:

--- world/makefile   2010-08-13 10:39:18.000000000 -0700

+++ world/makefile   2010-08-13 13:39:56.000000000 -0700

@@ -1,7 +1,7 @@



-HCC=$(shell ccache -V 2>/dev/null)

+HCC=$(shell ccache-swig -V 2>/dev/null)

 ifneq (,$(findstring version,$(HCC)))

-       CC=ccache gcc

+       CC=ccache-swig gcc

 else

        CC=gcc

 endif

@@ -11,7 +11,7 @@

 OUT=-o

 LINKOUT=-o

 NOLINK=-c

-DFLAGS=-DDEBUG=5 -DEQDEBUG=5 -DSHAREMEM -DCATCH_CRASH -DNO_PIDLOG -DFIELD_ITEMS -DIRC -Di386 -DAPP_OPCODE_SIZE=2

+DFLAGS=-DDEBUG=5 -DEQDEBUG=5 -DSHAREMEM -DCATCH_CRASH -DNO_PIDLOG -DFIELD_ITEMS -DIRC -DAPP_OPCODE_SIZE=2 -DFREEBSD -D__x86_64__

 WFLAGS=-Wall -Wuninitialized -Wwrite-strings -Wcast-qual -Wcomment -Wcast-align -Wno-deprecated



 PERL_FLAGS=$(shell perl -MExtUtils::Embed -e ccopts)

@@ -21,9 +21,9 @@

 MYSQL_FLAGS=$(shell mysql_config --cflags)

 MYSQL_LIB=$(shell mysql_config --libs)



-COPTS=$(WFLAGS) -g -march=i686 -O -pthread -pipe -I../common/SocketLib \

+COPTS=$(WFLAGS) -ggdb -march=native -pthread -pipe -I../common/SocketLib \

   -DFX -D_GNU_SOURCE -DINVERSEXY -DWORLD $(DFLAGS) $(MYSQL_FLAGS) $(PERL_FLAGS)

-LINKOPTS=$(COPTS) -rdynamic -L. -lstdc++ -lm -lz -ldl \

+LINKOPTS=$(COPTS) -rdynamic -L. -lstdc++ -lm -lz \

   $(MYSQL_LIB) $(PERL_LIB)



 all: world

pretty much the same change to the zone and eqlauncher makefiles.
Then I made a couple changes to the code which seemed to get it to compile and run allright:

Code:

--- common/Mutex.cpp     2010-08-12 10:39:24.000000000 -0700

+++ common/Mutex.cpp   2010-08-12 17:35:08.000000000 -0700

@@ -77,7 +77,7 @@

 #if defined(__CYGWIN__) || defined(__APPLE__)

        pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);

 #else

-       pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE_NP);

+       pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);

 #endif

        pthread_mutex_init(&CSMutex, &attr);

        pthread_mutexattr_destroy(&attr);

and a curious case with how money is handled:

Code:

--- zone/client.cpp      2010-08-12 10:40:42.000000000 -0700

+++ zone/client.cpp      2010-08-12 17:50:28.000000000 -0700

@@ -40,7 +40,6 @@

 #include <sys/socket.h>

 #include <netinet/in.h>

 #include "../common/unix.h"

-#define abs64 abs

 #endif



 extern volatile bool RunLoops;

@@ -2017,7 +2016,7 @@

                copperpp -= copper;

                if(copperpp <= 0)

                {

-                       copper = abs64(copperpp);

+                       copper = copperpp * -1;

                        m_pp.copper = 0;

                }

                else

@@ -2029,7 +2028,7 @@

                silver -= copper;

                if(silver <= 0)

                {

-                       copper = abs64(silver);

+                       copper = silver * -1;

                        m_pp.silver = 0;

                }

                else

@@ -2044,7 +2043,7 @@



                if(gold <= 0)

                {

-                       copper = abs64(gold);

+                       copper = gold * -1;

                        m_pp.gold = 0;

                }

                else

since the value of the money variable is already known to be below 0 (negative), and I'm not seeing anywhere in there you could end up with an imaginary number, I just flip the sign instead of going through the trouble of getting an absolute value.

I'll be pouring over those patches, see how it stacks up to what I was muddling through :)

The bsd.patch included with erde's autobuild scripts will fix the odd coin issue you are having, and also the mutex fix. The scripts may be out of date with the current svn, but its pretty simple to fix them. You just have to track down a new file or two and add it to one of the files included.

Yep. The link in the thread you pointed me to no longer works, but I found the latest version here.

I still needed to fix the issue with trying to use THREAD_MUTEX_RECURSIVE_NP instead of PTHREAD_MUTEX_RECURSIVE (easy fix, that), but everything else seems to be going well. I also noticed there was a new svn release the other day, so I'm trying this out with a fresh code base.

And no dice.:

Code:

embperl.o(.text+0xcf1): In function `xs_init':

: undefined reference to `boot_Object'

*** Error code 1

Seeing what I can do to track this one down. A missing XSLT header file, perhaps?

Upon further thought, a missing library makes no sense, as it was compiling using the default makefiles, and I have verified the presence of a defined symbol "boot_Object" in my already compiled zone. There must be a missing include somewhere.

Found it! zone/perl_object.cpp was not being compiled. Added an entry into the Makefile (and the Makefile.in and Makefile.am in the parent zone directory for future proofing) for perl_object and now it compiles and runs as expected.

Still getting an error, though:

Code:

[Error] Starting Log: logs/eqemu_error_zone.log

[Error] LoadEMuShareMemDLL::Load() failed to attach Items.GetItem

[Debug] [ZONE__INIT_ERR] Loading items FAILED!

[Debug] [ZONE__INIT] Failed.  But ignoring error and going on...

I'm going to guess items are still missing. :/ Oh wel, guess I'll keep plugging away at this...

Did you apply the SharedLibrary patch above and add the line to your jail host rc.conf? I'm sure that will fix your issue.

Yep, caught that after the last post. Now it's core-dumping:

Code:

cazic-thule> world

[Debug] Starting Log: logs/eqemu_debug_world.log

[Debug] [WORLD__INIT] Loading server configuration..

[Debug] [WORLD__INIT] Log settings loaded from log.ini

[Debug] [WORLD__INIT] CURRENT_WORLD_VERSION:EQEmulator 0.8.0

[Debug] [WORLD__INIT] Added loginserver duckberg.home:5998

[Debug] [WORLD__INIT] Connecting to MySQL...

[Status] Starting Log: logs/eqemu_world.log

[Status] Using database 'eqemu' at localhost:3306

[Debug] [WORLD__INIT] HTTP world service disabled.

[Debug] [WORLD__INIT] Loading variables..

[Debug] [COMMON__THREADS] Starting DBAsyncLoop with thread ID 24127216

[Debug] [WORLD__INIT] Loading zones..

[Debug] [WORLD__INIT] Clearing groups..

[Debug] [WORLD__INIT] Clearing raids..

[Debug] [WORLD__INIT] Loading items..

[Status] libEMuShareMem.so loaded

[Warning] requested shared memory of size:70848780 but that Key is already in use with size:1

[Warning] Attempting resize

[Error] Failed to resizeInvalid argument

Segmentation fault (core dumped)

cazic-thule>

I'm going to guess that the host system must be rebooted in order for security.jail.sysvipc_allowed to work properly (can't just say 'sysctl security.jail.sysvipc_allowed = 1'). Which will have to wait, as this unit also serves up DNS, CIFS, LDAP, HTTP, and I'm sure another half-dozen or so services I've long since forgotten about <:)

No luck. Still core dumping after reboot.

Forgot you will also need this in your jail host's /etc/sysctl.conf

Code:

#For EQEmu

kern.ipc.shmall=65536

kern.ipc.shmmax=134217728

#For EQEmu in a jail

security.jail.sysvipc_allowed=1

Reboot or use sysctl as necessary.

Thanks! It was kern.ipc.shmall that I was missing (64k is all it takes?). I was up late playing with values of shmmax (currently at 512M) and shmmin (currently back to default of 1).

I don't see any more errors regarding item loading, and it took a lot longer this time. Things are looking good!