Crashes / Disconnects

[John Adams]

I have a couple more crashes I am trying to track down. I had 2 players connected just now and logged in. My first attempt to connect failed with Loading UI resources for 5+ minutes... so I killed the client. Second attempt, I got right in. Soon as I got in, I simply /zone Baubbleshire to test something and crashed the world. No debug, but I am getting that set up now to see if I catch it.

Last night, only 2 crashes all night. So the worst is definitely behind us.

[LethalEncounter]

I just uploaded a fix for a deadlock crash too, so be sure to grab that.

[LethalEncounter]

I'm going to test a method of isolating any zone crashes to that instance of the zone. Theoretically if it works this will allow the server to just restart the zone without the entire World crashing.

[John Adams]

That sounds awesome. I'll watch for new code for the deadlock fix.

[John Adams]

Still not running newest code, but wanted to post this just in case it's different.

Code: Select all

>	EQ2WorldDebug.exe!std::operator<<<char,std::char_traits<char>,std::allocator<char> >(std::basic_ostream<char,std::char_traits<char> > & _Ostr={...}, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Str=<Bad Ptr>)  Line 569 + 0x2e bytes	C++
 	EQ2WorldDebug.exe!Mutex::lock()  Line 112 + 0x21 bytes	C++
 	EQ2WorldDebug.exe!LuaInterface::Process()  Line 114	C++
 	EQ2WorldDebug.exe!ZoneServer::Process()  Line 787	C++
 	EQ2WorldDebug.exe!ZoneLoop(void * tmp=0x0bcf3028)  Line 2883 + 0x8 bytes	C++
 	EQ2WorldDebug.exe!_callthreadstart()  Line 293 + 0xf bytes	C
 	EQ2WorldDebug.exe!_threadstart(void * ptd=0x0bceb128)  Line 277	C
 	kernel32.dll!77e64829() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	

The console reported this only:

Code: Select all

Possible deadlock attempt by '

[LethalEncounter]

It was already uploaded when I uploaded the parser fix.

[John Adams]

yeah, compiling it now. I just meant I had not restarted with the newest code in place yet, so this might not be a valid crash.

[John Adams]

Ok, latest dev SVN - and I took so long to get set up, my remote debugger wasn't running... but I saw one of those generic C++ runtime error boxes on the screen after we had done a few new spawnscript assignments and /repop's... so I started the remote debugger, quickly attached the process, and hit Retry. So if this call stack is meaningless, that's why heh. Hope it helps.

Code: Select all

>	EQ2WorldDebug.exe!std::_Debug_message(const wchar_t * message=0x00b4fb90, const wchar_t * file=0x00b4f658, unsigned int line=293)  Line 23	C++
 	EQ2WorldDebug.exe!std::_Tree<std::_Tmap_traits<Spawn *,unsigned char,std::less<Spawn *>,std::allocator<std::pair<Spawn * const,unsigned char> >,0> >::const_iterator::operator==(const std::_Tree<std::_Tmap_traits<Spawn *,unsigned char,std::less<Spawn *>,std::allocator<std::pair<Spawn * const,unsigned char> >,0> >::const_iterator & _Right=(0x002450fb {position_changed=false info_changed=false vis_changed=false ...},0))  Line 293 + 0x14 bytes	C++
 	EQ2WorldDebug.exe!std::_Tree<std::_Tmap_traits<Spawn *,unsigned char,std::less<Spawn *>,std::allocator<std::pair<Spawn * const,unsigned char> >,0> >::erase(std::_Tree<std::_Tmap_traits<Spawn *,unsigned char,std::less<Spawn *>,std::allocator<std::pair<Spawn * const,unsigned char> >,0> >::iterator _First=(0x002450fb {position_changed=false info_changed=false vis_changed=false ...},0), std::_Tree<std::_Tmap_traits<Spawn *,unsigned char,std::less<Spawn *>,std::allocator<std::pair<Spawn * const,unsigned char> >,0> >::iterator _Last=(0x002450fb {position_changed=false info_changed=false vis_changed=false ...},0))  Line 918 + 0x7e bytes	C++
 	EQ2WorldDebug.exe!std::_Tree<std::_Tmap_traits<Spawn *,unsigned char,std::less<Spawn *>,std::allocator<std::pair<Spawn * const,unsigned char> >,0> >::erase(Spawn * const & _Keyval=0x097ba188)  Line 936 + 0x51 bytes	C++
 	EQ2WorldDebug.exe!Player::ClearRemovedSpawn(Spawn * spawn=0x097ba188)  Line 1898	C++
 	EQ2WorldDebug.exe!ZoneServer::CheckSendSpawnToClient(Client * client=0x0956ae40)  Line 614	C++
 	EQ2WorldDebug.exe!ZoneServer::CheckSendSpawnToClient()  Line 644	C++
 	EQ2WorldDebug.exe!ZoneServer::SpawnProcess()  Line 692	C++
 	EQ2WorldDebug.exe!SpawnLoop(void * tmp=0x09548c48)  Line 2893 + 0x8 bytes	C++
 	EQ2WorldDebug.exe!_callthreadstart()  Line 293 + 0xf bytes	C
 	EQ2WorldDebug.exe!_threadstart(void * ptd=0x059f44d8)  Line 277	C
 	kernel32.dll!77e64829() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	

[LethalEncounter]

I'm about to check in a new version that will try to handle exceptions automatically. Note that I had to enable an option in Visual Studio to get it to work on windows (C/C++ Code Generation >> Enable C++ Exceptions >> Yes With SEH Exceptions (/EHa). If you want to test it out, either use the compiled Win32 exe file I uploaded, or enable that option.

BTW, I fixed both a client crash and server crash in this update as well.

[John Adams]

Will we still be able to debug like I have been doing to trap crashes or break into the code like I currently do?

Putting your exe on Tess, though on my server the /test command is for you and I only.

[LethalEncounter]

Yup, debugging will still work like normal. In debug mode you have to hit retry before it passes the exception onto the program.

[John Adams]

Another thing that keeps happening to me a lot more than ever before, I log in and wait for a moment then decide to /zone somewhere else and get all hung up. Is this a mini-desynch do you think?

zone.jpg

This is what my client sticks on, 4-evar!

zone2.jpg

World is happy, far as I can tell. Any idears?


Edit: Hmm! After a few mins to post this complaint, I exited my client and the console revealed more info. This looks like what I see during desynch, so that's prolly it.

zone3.jpg

Kinda odd that Baubbleshire would shut down >after< Queen's Colony, when I supposedly had already left Baubbleshire and was supposed to be in QC at the time of the disconnect.

[Jack]

I've the same problem as John. Zoning occasionally freezes up at different sequences of loading(Logging in, creating identities, etc). I've even had the problem once or twice logging into character selection.

I lose connection to the server at character selection and creating a character after about 1-2 minutes as well.

[paulgh]

This latest issue may be due to a client bug, as the same thing happened to me on live last night. Over the past month or two there have been 7 or 8 occasions where I was stuck at that same point, but it continued after about 2 minutes. Last night I gave up and exited at 5 minutes.

Paul

[John Adams]

Yup, debugging will still work like normal. In debug mode you have to hit retry before it passes the exception onto the program.

I think trying to figure out the crash is not going to work like it used to, since I have remote debugging on, running a debug world exe and am crashing the shit out of my ZoneServer::ClientProcess() constantly and catching nothing in debugger. I guess you mean if the world crashes completely, debugging should work like it used to?