Anyone else see these issues recently?
 

I'm doing a standard build and install of the source (svn) and everything seems to usually run ok, but I see these issues cropping up :
1 > Any player-character's death seems to clobber the zone (zone reboot) and, of course, the character's client seems to just stay there until it realizes it's disconnected (both Underfoot and Titanium were tested).

2 > Most of the time, when the server is started, quests that involve giving and/or taking items don't work (for example, handing the exterminator four whiskers (not stacked)). The deletes from player inventory shows in the log but nothing else.

Quests that involve just conversation seem to work.

Have I configured something wrong?

This is 32-bit Ubuntu 11.10, with the newest source, peqdb, maps as of yesterday.

I've done forum searches and can't find this/these.

1-make sure you have latest from svn and all required sql files sourced.

2- did you copy plugins into quest folder?

Yup.. I copied the quests to the quests subdirectory. I thought putting the full path to the quests dir in the eqemu_config.xml would be enough... but it wasn't...
I put the quests "back" up one directory instead, and it seems to work great. That's totally ok.

Will try the sql reload later.

Thanks.

Ok, I reloaded the database... here are the steps for that :

drop database if exists peqdb;
create database if not exists peqdb;
use peqdb;
source /home/eqemu/source/peqdatabase/drop_system.sql
source /home/eqemu/source/peqdatabase/drop_player.sql
source /home/eqemu/source/peqdatabase/drop_login.sql
source /home/eqemu/source/peqdatabase/drop_bots.sql
source /home/eqemu/source/peqdatabase/peqdb_rev2100.sql
source /home/eqemu/source/peqdatabase/load_player.sql
source /home/eqemu/source/peqdatabase/load_login.sql
source /home/eqemu/source/peqdatabase/load_bots.sql
source /home/eqemu/source/EQEmuServer/EQEmuLoginServer/login_util/EQEmuLoginServerDBInstall.sql

It's version 2100, and I think that's the newest, and there seem to be no updates beyond that.

Then I restart the server... and intentionally get killed by a rat (way harder than they appear) and get this as the only error that I can see :

eqemu_debug_3848.log:[03.08. - 17:02:44] [LAUNCHER__STATUS] Zone dynamic_05 has gone down. Restart timer started.
eqemu_debug_world.log:3847 [03.08. - 17:02:44] [WORLD__ZONELIST] Removing zoneserver #5 at :7004
eqemu_debug_world.log:3847 [03.08. - 17:02:44] [WORLD__ZONELIST] Hold Zones mode is ON - rebooting lost zone
eqemu_debug_world.log:3847 [03.08. - 17:02:44] [WORLD__LAUNCH] zone: dynamic_05 reported state STOPPED (1 starts)

There is an update in the server SVN beyond DB 2100.
2104_required_group_roles.sql

Also your drop statements are redundant since you dropped the entire database first.

True, regarding the drop statements.

The update only mucks with the group-leaders. I reloaded the db and re-ran it (that following update 2104).

ALTER TABLE `group_leaders` ADD COLUMN `maintank` VARCHAR(64) NOT NULL DEFAULT '' AFTER `leadershipaa`;
ALTER TABLE `group_leaders` ADD COLUMN `puller` VARCHAR(64) NOT NULL DEFAULT '' AFTER `assist`;

But it didn't seem to affect the problem with a character death restarting the zone.

Should there be a place I can look? Can I activate more debugging info? Is there a log that might have more relevant information?

Here's the log from when someone dies
 

Now, I have to admit that log.ini is an empty file.

I see no errors in booting up -- I will post that log next.

Bootup logs
 

The only problem this server is having is that when a user dies, the user gets disconnected (eventually) and their client "dies" -- the server seems to kill the zone.

Here is full log (minus command-inits) of start-up to first log in for that single user (using the Titanium client) :

[BEGIN] 3/9/2012 4:24:11 PM

Player now sees client as in zone.

I'm not familiar with running the server on Linux, but there should be a way to debug the zone to get a call stack from where the crash occurred. That would be the most useful to help figure out where the issue is. I'm sure someone here could help you with that if you don't know how to.

Ok, figured it out.

It's the same issue as : http://67.23.190.71/forums/showthread.php?t=30809

And it was also fixed by :

Derision's suggesting :

It appears to be crashing in the assembler in common/crc32.cpp.

Maybe a GCC version related issue (I use 4.1.1 without issue).

A quick thing to try rather than downgrading your GCC version would be to edit common/crc32.cpp and change line 175 from:
Code:
#elif defined(i386)
to
Code:
#elif defined(i386xxx)
and recompiling, so it should fall back to using the C version of the CRC code instead of the assembler.