[FIXED]World Crash = quest_id = 0

[John Adams]

In all my years, I have never seen this one Jcllord (god almighty?) logged in and got quite a number of quests shot at him

11:02:51 D Player: Getting current title index for player 'Jcllord'...
11:02:51 D Player: Getting current title index for player 'Jcllord'...
11:02:51 D Merchant: Loading Buyback - Player: 369
11:02:51 D Player: Jcllord left grid 4294967295 and entered grid 1698999948
11:02:55 D Command: Player 'Jcllord' (4406), Command: autoattack
11:02:55 D Command: Player 'Jcllord' (4406), Command: enablequeuedabilities
11:02:55 D Command: Player 'Jcllord' (4406), Command: welcome_info
11:02:55 I Command: Unhandled command: welcome_info
11:03:00 E Client: num_quests = 542403164
11:03:00 E Client: quest_id = 2188672662
11:03:00 E Client: quest_id = 0
11:03:00 E Client: quest_id = 0

and so it continued a very rapid burp until the log buffer exploded, and this is what I saw when I logged in:

burp.jpg

That's new...

The call stack may be useless, because I think the crash was caused by the logging buffer and not whatever caused the loop.

Code: Select all

 	kernel32.dll!77e4bef7() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	kernel32.dll!77e4bef7() 	
>	EQ2World.exe!_unlock(int locknum)  Line 375	C
 	EQ2World.exe!_unlockexit()  Line 785 + 0x7 bytes	C
 	EQ2World.exe!_onexit(int (void)* func)  Line 90 + 0x5 bytes	C
 	EQ2World.exe!__CTA2?AVbad_alloc@std@@()  + 0xb bytes	C++
 	EQ2World.exe!005d1efb() 	
 	EQ2World.exe!std::allocator<EQStream *>::allocate(unsigned int _Count)  Line 187 + 0x1b bytes	C++
 	EQ2World.exe!std::vector<Client *,std::allocator<Client *> >::reserve(unsigned int _Count)  Line 754	C++
 	EQ2World.exe!std::vector<Client *,std::allocator<Client *> >::_Reserve(unsigned int _Count)  Line 1298	C++
 	EQ2World.exe!std::vector<unsigned int,std::allocator<unsigned int> >::push_back(const unsigned int & _Val)  Line 995	C++
 	EQ2World.exe!ZoneServer::CheckSpawnRange(Client * client, bool initial_login)  Line 849 + 0xd bytes	C++
 	EQ2World.exe!ZoneServer::CheckSpawnRange()  Line 870	C++
 	EQ2World.exe!ZoneServer::SpawnProcess()  Line 981	C++
 	EQ2World.exe!SpawnLoop(void * tmp)  Line 4937 + 0xa bytes	C++
 	EQ2World.exe!_callthreadstart()  Line 259 + 0x6 bytes	C
 	EQ2World.exe!_threadstart(void * ptd)  Line 241 + 0x5 bytes	C
 	kernel32.dll!77e6481f() 	

Maybe installing some safety nets around our array sizes so they are not valid if in the millions?

[John Adams]

This bug is not going to go away on it's own. I've looked into it briefly, and cannot figure out why a 1096 client would get the same thing as a current live client - so I don't think I can blame struts.

Latest crash, after only 3 connections:

08:31:53 E Client: num_quests = 1809203642
08:31:53 E Client: quest_id = 961791130
08:31:53 E Client: quest_id = 0

again, the logwrite buffer was hit so hard, eventually it overflowed and crashed the world.


Edit: I have hacked what might resolve the crashing, but the num_quests = billions is still incorrect for some reason. My fix will likely break the Quest system for players exhibiting this behavior, so it is not the solution. I will still need Jabantiz to look into it and provide a valid fix.

Code on Dev SVN.

[Jabantiz]

08:31:53 E Client: num_quests = 1809203642

This is the core of the issue no clue what is causing this to happen. By any chance do you know if this is on a character with no quests or one with, or does it happen in both cases?

PS - Sorry rl is still kicking my ass with no sign of it letting up, trying to find time to look into all these issues but can't seem to get any

[Jabantiz]

Briefly looked into this and the code is in response to a client packet. This means that there is either a struct issue or a desync, as this has been around since before CoE I will tend to lean towards a desync. This code also looks to be for tracking quest so the solution you put in place should only effect quest tracking on log in, the client should be able to fix it after getting into the game, this is assuming it is not a desync issue. It won't kill the quest system for the player if they are able to get in.

[John Adams]

Excellent. I inadvertently fixed something? I kinda figured it could be desync, because those numbers were ridiculous. As long as the server isn't looping 2bil times, and Quests still work, I'll call it fixed.

Thanks for looking into it, Jab.