Help on a core dump
 

I recently went from r2142 to r2172 and I am getting a core dump as soon as I spawn a bot. Any help would be appreciated...

I just tried a few more things, clicking on a door or an npc also crashes the zone.

Try rev 2175. The bot issue should be fixed there.

I think the perl issue may be resolved as well..there was an extra argument added around 2173-2174.

My bad, that was r2175, I just checked.

When you load the core file up, type 'bt' to get a callstack and we can take a look at where it went wrong.

On a side note, I had these same problems months ago when I went from r2142 to r2146. On this dump all I did was click on a mob on the screen. Back on r2142 until I figure out what the hell I am doing wrong.

I notice at r2145 there was a change to quest parser and it is at that exact same line. Still investigating what is missing, or maybe something in my database is corrupt, an old quest or task ? I checked for missing SQL but there is nothing around that revision as far as changes, all other changes are not related to the quest parser. Even after running the SQL updates, it still crashed because I ran them last night.

bt

bt full

I don't know anything about unix, but it looks like your client assignments are long instead of int32.

16-bit 0xFFFF
32-bit 0xFFFFFFFF
48-bit 0xFFFFFFFFFFFF
64-bit 0xFFFFFFFFFFFFFFFF

this = 0x7fc5dc0c86f0 (assuming this is the client id. If it's a memory pointer, then I don't know...)

EDIT: That would be over 127 terabytes of memory though..if it were a pointer...

I am using the UF client, I did not turn on VoA or anything before the compile. There was something that happened between those two revisions, if I could read C++ better I could probably figure it out. If I have time this weekend I may spin off a VM and do an install from scratch with a fresh database and go from there.

Yard work is killing me today, hot as hell in Alabama right now. When I get back inside I imagine my energy will be zapped.

'this' is a pointer to the current object. You may have seen code that does something like this->DoSomething(); or this->somevariable = 42; or maybe not since the the this pointer is always assumed so it's fairly rare that you actually need to specify it in code, but it is passed to any member function automatically which is why you'll see it in a stack trace.

Those look like 64-bit pointers to me. They look odd to me too, but keep in mind that virtual address != physical address, so if the OS decides to map the address space somewhere that seems weird it doesn't mean it wouldn't still work. I don't debug a lot of 64-bit apps on Linux so I don't know what looks normal.

The lines numbers in svn don't seem to match up with the core dump, but looking at QuestParserCollection::EventPlayer nothing jumps out as horribly wrong. It appears to check for valid pointers, and it doesn't do anything particularly exciting. It could be a 64-bit only thing, but I'd guess there's at least a few other people running that so if it was a general issue there'd be some freaking out.

I'd search a bit for the global player.pl change in the forums here. I remember someone having some sort of problem, and maybe the solution is there. I think it was Stormhaven that had trouble, and maybe they needed to add that global file somewhere? *shrug*

Aha! Try this: http://www.eqemulator.org/forums/sho...d.php?p=210530

Somehow I missed your reply Lex, much appreciated ! And yes that was causing one of the zone crashes, I source in quests and copied my custom quest over on top of those and it fixed those errors.

Now I have one more regarding bots. Players can use old bots just fine, but if we create new bots and spawn them right after they spawn they cause the zone to crash.
And first glance I would say it was something to do with the new bot timer table but I sourced that in again and all of my SQL is up to date. I wonder if this could be a linux only issue ? I know Linux is more picky on upper / lower case on the tables.

BT dump.....

BT FULL

Please run that query in the dump and let me know the results. It may be something with the max timer or something, especially if you have custom spells.

The query was chopped off in the core dump but I copied what I could from it and copied some from the bot.cpp file in the source.

The query came back as null (no results) when I set the class variable to 1. I know nulls are supposedly evil, would a null result set cause a crash ?

Not necessarily. If there's no results, it shouldn't execute the loop where it processes the results, which is where the error is being caused. It's more likely that it is returning a row, but one of the values is null, most likely MaxValue. Is the bot id'd in the error a warrior? If not, figure out what class they are and use that. Is it all new bots, or just a specific class?

The only thing I can think of is MaxValue is null, so I need to figure out how to get the sunquery to return null. It may be difficult to reproduce, because you most likely need a timer in there to get some results.

I'll try to reproduce this when I get a chance.

If there are no players on at lunch I will copy r2185 back over and try a few bots. I want to saw the one that definitely crashed it was a warrior. I will report back with more information sometime today.

I had a brief chance to try it this morning. I know it seg faulted on a Human Warrior, Barbarian Shaman and an Erudite Mage. Any old bots work fine, verified that.

This should be fixed in rev 2192.