NT Crash Thread

[Moldew]

Is that my cue to come break something?!?

[Lokked]

See this thread: viewtopic.php?f=22&t=1180

[John Adams]

Tons of people on (YAY) for a long period of time, but finally the world had to collapse

Stack:

Code: Select all

>	WorldServer.exe!WorldCharacter::GetInventory() Line 1788	C++
 	WorldServer.exe!ChunkServer::HandleClientInvMove(std::shared_ptr<Client> & client, PacketStruct * packet) Line 2186	C++
 	WorldServer.exe!ChunkServer::ProcessPackets() Line 516	C++
 	WorldServer.exe!ChunkPacketThread(void * data) Line 134	C++
 	WorldServer.exe!ThreadRun(void * arg) Line 77	C++
 	WorldServer.exe!_callthreadstart() Line 255	C
 	WorldServer.exe!_threadstart(void * ptd) Line 239	C
 	kernel32.dll!7689338a()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	ntdll.dll!76f99f72()	Unknown
 	ntdll.dll!76f99f45()	Unknown

Another place we are setting objects, then using them without checking they are valid.

Empty:

Code: Select all

auto origin_character = client->GetCharacter();

Crash, ChunkServer.cpp, Line 2186

Code: Select all

Inventory* char_inventory = origin_character->GetInventory();

Whether we should have to or not, it is 90% of our crashes. We should probably just check them all every time we add one.


Edit: Oh, this code has changed on SVN -- nm, I think Zippy already found it

[Lokked]

As a reminder, any GetCharacter, GetCurrentChunk and GetClient should then be checked in the next line.

This is because these are general std::weak_ptr<>.lock calls. If the object doesn't exist in the first place, .lock will return a nullptr.

[John Adams]

For those waiting, give me 5 mins to reconfig the firewalls. I am moving NT to a dedicated bare metal box.

[Cyrcle]

[quote="John Adams"]For those waiting, give me 5 mins to reconfig the firewalls. I am moving NT to a dedicated bare metal box.[/quote]
Woohoo

[zippyzee]

Crap! I hate that I broke the streak. I have been going back in and trying to find all of these. On the other hand, there should always be a character, correct? They initiated the inventory move. So when it fails to get the character, is that just a symptom of another issue or are there instances where there just will be no character there (chunking, exiting the client) and all else is good?

[John Adams]

[quote="Cyrcle"][quote="John Adams"]For those waiting, give me 5 mins to reconfig the firewalls. I am moving NT to a dedicated bare metal box.[/quote]
Woohoo[/quote]
Online, please test logging in.


[quote="zippyzee"]Crap! I hate that I broke the streak. I have been going back in and trying to find all of these. On the other hand, there should always be a character, correct? They initiated the inventory move. So when it fails to get the character, is that just a symptom of another issue or are there instances where there just will be no character there (chunking, exiting the client) and all else is good?[/quote]
zippy, never assume anything with stupid_ptr's

[zippyzee]

I'll make it a priority to check everywhere else. If the new revision is up there should be some significant item system stabilization and general bug-squashage.

[Lokked]

[quote="zippyzee"]Crap! I hate that I broke the streak. I have been going back in and trying to find all of these. On the other hand, there should always be a character, correct? They initiated the inventory move. So when it fails to get the character, is that just a symptom of another issue or are there instances where there just will be no character there (chunking, exiting the client) and all else is good?[/quote]

First, a very calm and collected "No" because with a multithreaded environment in development, it's difficult to rely on object lifetimes. However, once we sort out a few things, then these types of situations should never occur.

Second, a loud and obnoxious "NO" because stability is very low. What happened is his chunk client probably failed, due to this who ResendPacket issue, and so it's object was destroyed. This destroys his character object. He was still connected and producing packets to the server because his World Client was still connected.

It's confusing, but .... I have no positive comment to add after making that statement