Worldserver Crash ( Access violation )

[Terrat]

Hey ho,
mein Worldserver ist mir abgeschmiert (Debug). (Passiert immer unterschiedlich mal 7 stunden mal 10 mal 3 stunden.)

Output:

mafl_kingaide_0 key:#auto
mafl_heavenman_0 key:#auto
CDPDatabaseClient.OnLEventTickCDPDatabaseClient.OnLordSkillTickFirst-chance exception at 0x0079d326 in WorldServer.exe: 0xC0000005: Access violation reading location 0x0000000c.
Unhandled exception at 0x76fb15ee in WorldServer.exe: 0xC0000005: Access violation reading location 0x0000000c.

Disassembly:76FB15BD add esp,4

76FB1590  mov         eax,12Ch 
76FB1595  xor         ecx,ecx 
76FB1597  lea         edx,[esp+4] 
76FB159B  call        dword ptr fs:[0C0h] 
76FB15A2  add         esp,4 
76FB15A5  ret         18h  
76FB15A8  mov         eax,12Dh 
76FB15AD  mov         ecx,0Ah 
76FB15B2  lea         edx,[esp+4] 
76FB15B6  call        dword ptr fs:[0C0h] 
---->76FB15BD  add         esp,4
76FB15C0  ret         0Ch  
76FB15C3  nop              
76FB15C4  mov         eax,12Eh 
76FB15C9  xor         ecx,ecx 
76FB15CB  lea         edx,[esp+4] 
76FB15CF  call        dword ptr fs:[0C0h] 
76FB15D6  add         esp,4 
76FB15D9  ret         18h  
76FB15DC  mov         eax,12Fh 
76FB15E1  xor         ecx,ecx 
76FB15E3  lea         edx,[esp+4] 
76FB15E7  call        dword ptr fs:[0C0h] 
76FB15EE  add         esp,4 
76FB15F1  ret         0Ch  
76FB15F4  mov         eax,130h 
76FB15F9  xor         ecx,ecx 
76FB15FB  lea         edx,[esp+4] 
76FB15FF  call        dword ptr fs:[0C0h] 
76FB1606  add         esp,4 
76FB1609  ret         18h  
76FB160C  mov         eax,131h 
76FB1611  xor         ecx,ecx 
76FB1613  lea         edx,[esp+4]

[Terrat]

Was macht die Funktion ?
OnLordSkillTick

void CDPDatabaseClient::OnLordSkillTick( CAr & ar, DPID, DPID )
{
	election::OutputDebugString( "CDPDatabaseClient.OnLordSkillTick" );

	CLordSkill* pSkills		= CSLord::Instance()->GetSkills();
	pSkills->SerializeTick( ar );
	if( CSLord::Instance()->Get() == NULL_ID )
		return;
	CUser* pLord	= g_UserMng.GetUserByPlayerID( CSLord::Instance()->Get() );
	if( IsValidObj( pLord ) )
		pLord->AddLordSkillTick( pSkills );
}

void CDPDatabaseClient::OnLEventTick( CAr & ar, DPID, DPID )
{
	election::OutputDebugString( "CDPDatabaseClient.OnLEventTick" );
	ILordEvent* pEvent		= CSLord::Instance()->GetEvent();
	pEvent->SerializeTick( ar );
	g_UserMng.AddLEventTick( pEvent );
	pEvent->EraseExpiredComponents();
}

[xTwiLightx]

Du solltest dir einfach mal den Stack der Funktion zum Zeitpunkt des Crashes anschauen, mit Diassembly können wir nämlich nicht viel anfangen.

[Terrat]

Hört sich zwar jetzt blöd an, aber ist da oben nicht im Bild der Callstack

[Wanetrain]

Originally Posted by IceGuard™✔

Hört sich zwar jetzt blöd an, aber ist da oben nicht im Bild der Callstack

Hört sich zwar auch ganz blöd an aber wie wäre es wenn du einfach die Finger von Visual Studio lässt? o.O

Upgrade dein Source auf VS 2010+, dann hast du immerhin schonmal ein besseren Debugger am start, dann kick die Funktion wo es Crasht einfach weg. Hast deine Ruhe. Denn für's Fixxen hast du zu wenig wissen wenn du nichtmal mit Visual Studio umgehen kannst.

Soll jetzt nicht beleidigend klingen aber so langsam reicht es auch mit dein Threads..

Aber um es dir kurz zu erklären: alles was mit "GetInstance" Fungiert ist Schrott, da man früher oder später einfach die Instance verliert.

Würdest du VS 2012 nutzen könnte ich dir easy going zeigen wieviel Memory Leaks und Fehler der Source enthält was nichtmal wer kapiert..das echt traurig.. :/

[xTwiLightx]

Originally Posted by IceGuard™✔

Hört sich zwar jetzt blöd an, aber ist da oben nicht im Bild der Callstack

Callstack != Memory Stack

Im Memory Stack kann man die Variablen und deren Inhalt einsehen, zumindest kann ich das mit VS2012. Ob VS.NET das auch kann, weiß ich nicht. Du solltst aber im unteren linken Tab mal die "locals" checken.

Originally Posted by Wanetrain

Hört sich zwar auch ganz blöd an aber wie wäre es wenn du einfach die Finger von Visual Studio lässt? o.O

Upgrade dein Source auf VS 2010+, dann hast du immerhin schonmal ein besseren Debugger am start, dann kick die Funktion wo es Crasht einfach weg. Hast deine Ruhe. Denn für's Fixxen hast du zu wenig wissen wenn du nichtmal mit Visual Studio umgehen kannst.

Soll jetzt nicht beleidigend klingen aber so langsam reicht es auch mit dein Threads..

Aber um es dir kurz zu erklären: alles was mit "GetInstance" Fungiert ist Schrott, da man früher oder später einfach die Instance verliert.

Würdest du VS 2012 nutzen könnte ich dir easy going zeigen wieviel Memory Leaks und Fehler der Source enthält was nichtmal wer kapiert..das echt traurig.. :/

Son Guide für das Detecten von Memory Leaks würde mich schon interessieren.

[Wanetrain]

Originally Posted by xTwiLightx

Callstack != Memory Stack

Im Memory Stack kann man die Variablen und deren Inhalt einsehen, zumindest kann ich das mit VS2012. Ob VS.NET das auch kann, weiß ich nicht. Du solltst aber im unteren linken Tab mal die "locals" checken.

Son Guide für das Detecten von Memory Leaks würde mich schon interessieren.

Es gibt in Visual Studio 2013 mehrere Debug Methoden, welche aber auch in 2012 vorhanden sein müssten meines wissens nach. Dazu könnte man Thread Building Blocks noch dazu hauen, den Visual Studio Profiler, will man dann die Neuz Debuggen braucht sie halt eiskalt mal 30~50min zum Starten, davor 1h zum Compilen, verbraucht ca. 1.9GB an Arbeitsspeicher, wird aber dafür Komplett durchgehauen was alles angeht, ist halt echt bissel Heavy für "Speed" Entwickler. Lohnt sich auch nicht für FlyFF Source Developer da die meisten Memory Leaks nicht einfach zu Fixxen sind wenn man keine ahnung von C++ hat. Das meiste ist Stack & Heap alloc was nicht grad der hammer ist, aber auch fehlerhafte's SAFE_DELETE, was zum großteil allerdings die meisten Leaks erzeugt ist der MemPooler, welcher die ganzen kack Pointer auch nicht wirklich löschen tut was er eigentlich sollte.

Weißt du denn überhaupt was ein "Memory Leak" ist?

[WurstbrotQT]

Wtf, dass man Singleton Instanzen verlieren kann wusste ich nicht, dachte immer das Problem sei, dass man die Instanzen nicht verliert und dass man den Instanzstatus über die komplette Laufzeit hat. Also quasi pseudo globals wrapped in ne klasse

Btw, hab mal dieses __VERIFY_MEMPOOL definiert, was ja ok Prinzip den Pooler ausstellt, hab keine leaks finden können, für das Problem muss man scheinbar tiefer graben

[xTwiLightx]

Originally Posted by Wanetrain

Es gibt in Visual Studio 2013 mehrere Debug Methoden, welche aber auch in 2012 vorhanden sein müssten meines wissens nach. Dazu könnte man Thread Building Blocks noch dazu hauen, den Visual Studio Profiler, will man dann die Neuz Debuggen braucht sie halt eiskalt mal 30~50min zum Starten, davor 1h zum Compilen, verbraucht ca. 1.9GB an Arbeitsspeicher, wird aber dafür Komplett durchgehauen was alles angeht, ist halt echt bissel Heavy für "Speed" Entwickler. Lohnt sich auch nicht für FlyFF Source Developer da die meisten Memory Leaks nicht einfach zu Fixxen sind wenn man keine ahnung von C++ hat. Das meiste ist Stack & Heap alloc was nicht grad der hammer ist, aber auch fehlerhafte's SAFE_DELETE, was zum großteil allerdings die meisten Leaks erzeugt ist der MemPooler, welcher die ganzen kack Pointer auch nicht wirklich löschen tut was er eigentlich sollte.

Weißt du denn überhaupt was ein "Memory Leak" ist?

Meines Wissens nach (was natürlich auch falsch sein kann) Stellen im Code, wo allocated Memory nicht mehr freigegeben wird.
Resultat: Der Arbeitsspeicher wird voller und voller.

[Wanetrain]

Originally Posted by WurstbrotQT

Wtf, dass man Singleton Instanzen verlieren kann wusste ich nicht, dachte immer das Problem sei, dass man die Instanzen nicht verliert und dass man den Instanzstatus über die komplette Laufzeit hat. Also quasi pseudo globals wrapped in ne klasse

Btw, hab mal dieses __VERIFY_MEMPOOL definiert, was ja ok Prinzip den Pooler ausstellt, hab keine leaks finden können, für das Problem muss man scheinbar tiefer graben

CLord ist dafür ganz bekannt, sowieso der Datenbank Server. Du kannst solche Instanzen Verlieren, geht sogar leichter als man möchte.