Worldserver Crash ( Access violation )

01/31/2015 14:28 Terrat#1
Hey ho,
mein Worldserver ist mir abgeschmiert (Debug). (Passiert immer unterschiedlich mal 7 stunden mal 10 mal 3 stunden.)

Output:
Code:
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
Code:
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]
[Only registered and activated users can see links. Click Here To Register...]
02/02/2015 00:27 Terrat#2
Was macht die Funktion ?
OnLordSkillTick
Code:
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();
}
02/02/2015 11:06 xTwiLightx#3
Du solltest dir einfach mal den Stack der Funktion zum Zeitpunkt des Crashes anschauen, mit Diassembly können wir nämlich nicht viel anfangen.
02/02/2015 13:20 Terrat#4
Hört sich zwar jetzt blöd an, aber ist da oben nicht im Bild der Callstack :o
02/02/2015 14:10 Wanetrain#5
Quote:
Originally Posted by IceGuard™✔ View Post
Hört sich zwar jetzt blöd an, aber ist da oben nicht im Bild der Callstack :o
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.. :/
02/02/2015 15:39 xTwiLightx#6
Quote:
Originally Posted by IceGuard™✔ View Post
Hört sich zwar jetzt blöd an, aber ist da oben nicht im Bild der Callstack :o
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.
Quote:
Originally Posted by Wanetrain View Post
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.
02/02/2015 16:24 Wanetrain#7
Quote:
Originally Posted by xTwiLightx View Post
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?
02/02/2015 17:50 WurstbrotQT#8
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 :D

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 :D
02/02/2015 17:54 xTwiLightx#9
Quote:
Originally Posted by Wanetrain View Post
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.
02/02/2015 20:13 Wanetrain#10
Quote:
Originally Posted by WurstbrotQT View Post
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 :D

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 :D
CLord ist dafür ganz bekannt, sowieso der Datenbank Server. Du kannst solche Instanzen Verlieren, geht sogar leichter als man möchte.