Page 7 of 14

Re: NT Crash Thread

Posted: Wed Jan 28, 2015 4:40 pm
by John Adams
Lokked, I have a linux machine for VGO Dev server (Login runs there as well). If someone tells me what to do, I can put New Telon over there for a week with Valgrind running.

Re: NT Crash Thread

Posted: Wed Jan 28, 2015 4:57 pm
by Lokked
To be honest, I wouldn't even know what you should be expecting or looking for. If we have a Valgrind expert (Kandra?) to assist you, this may be a viable strategy.

Re: NT Crash Thread

Posted: Thu Jan 29, 2015 4:14 am
by Kandra
I would not use Valgrind for the VGO server if I wasn't forces to do it. Maybe in a test where one starts the server, connects a client, disconnects, and then terminate the server. Anything more than that would probably be way to complicated to analyse.
Valgrind would also make the server run horrible slow and use lots of memory.

Instead I recommend that someone gives SonarQube a try since I've heard that it can do static code analysis. But I have never used it myself.

Re: NT Crash Thread

Posted: Thu Jan 29, 2015 4:01 pm
by John Adams
Kanrda, not sure if you're into Microsoft, but won't the Visual Studio "Code Analysis" tell us anything useful? I ran it before on EQ2, read a few lines and closed the window in terror. But it seems to say a lot.

Edit: Just ran it on VGO code, and surprisingly this does seem to point out a potential crash... Lokked, maybe we need to do this?
[attachment=0]codeanalysis2.jpg[/attachment]


Edit2: Jeepers, Lokked - this sounds scary. Soothe my fears

[quote]C6262 Excessive stack usage Function uses '65620' bytes of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap. WorldServer configreader.cpp 92[/quote]

[quote]C26110 Caller failing to hold lock Caller failing to hold lock 'this->lock' before calling function 'ReleaseSRWLockExclusive'. WorldServer mutex.cpp 204[/quote]

Re: NT Crash Thread

Posted: Thu Jan 29, 2015 5:32 pm
by Lokked
Lol, that's actually kinda funny. It happens. We're saying, "If the pointer is NULL, dereference it to get faction_id". This would instantly crash. That logerror should not try to access any part of "info".

The first quote is fine. It's a single Stack Frame that's going over the preset warning limit. If it was a threaded function (and so each thread would have a stack frame this size), then it's excessive and would eat up a lot of memory.

Second one, no idea.

Re: NT Crash Thread

Posted: Thu Jan 29, 2015 5:36 pm
by John Adams
I am curious about the Mutex issue, since we seem to have problems with lock. Though both those quoted code lines are like day-1 code so they had to have been issues all along.

Re: NT Crash Thread

Posted: Thu Jan 29, 2015 5:40 pm
by Lokked
Pertaining to Mutex.Lock():
I fixed, or at least identified, the recent problems (at least, it covers all problems regarding lock reported so far) about 2 weeks ago.

The cause is this:
Client objects weren't being fully created, and then were being used as if they were created. One aspect of Client is the mutex's. The error with lock was due to the mutex not being initialized (because the Client object wasn't created properly) and what happens when you try to access an uninitialized object? Crash! If you recall from previous error reports, lock was empty. It was empty because it was never initialized.

Re: NT Crash Thread

Posted: Thu Jan 29, 2015 5:44 pm
by John Adams
Ahh okay, yeah I thought I hadn't seen that bugger any longer

Re: NT Crash Thread

Posted: Fri Jan 30, 2015 12:40 am
by Kandra
I'm only using Visual Studio in some of my own hobby projects, but have never used it professionally. But it seems to be a good start at least. Anything related to dereference null pointers is really dangerous but often quite easy to fix. On most systems it will cause an instant crash, but on some other it can lead to strange behaviors.

Re: NT Crash Thread

Posted: Sat Feb 07, 2015 9:36 am
by John Adams
Just got another random heap crash on an Unlock, don't see these too often

Stack

Code: Select all

 	ntdll.dll!77420574()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!774057c2()	Unknown
 	ntdll.dll!773e2a8a()	Unknown
 	ntdll.dll!773b1d17()	Unknown
>	WorldServer.exe!_unlock(int locknum) Line 366	C
 	WorldServer.exe!_heap_alloc_dbg_impl(unsigned int nSize, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp) Line 507	C++
 	WorldServer.exe!_heap_alloc_dbg_impl(unsigned int nSize, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp) Line 504	C++
 	00610000()	Unknown
Threads

Code: Select all

Not Flagged	>	2940	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!_unlock	Normal
Not Flagged		352	0	Main Thread	Main Thread	WorldServer.exe!SleepMS	Normal
Not Flagged		752	0	Worker Thread	ntdll.dll thread	ntdll.dll!7737015d	Normal
Not Flagged		1836	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!SleepMS	Normal
Not Flagged		664	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!SleepMS	Normal
Not Flagged		1984	0	Worker Thread	WorldServer.exe!_threadstart	mswsock.dll!74c36f1f	Normal
Not Flagged		2716	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!SleepMS	Normal
Not Flagged		332	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!_read_nolock	Normal
Not Flagged		2648	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!std::_Iterator_base12::_Adopt	Normal
Not Flagged		912	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!SleepMS	Normal
Not Flagged		148	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!SleepMS	Normal
Not Flagged		2296	0	Worker Thread	WorldServer.exe!_threadstart	WorldServer.exe!SleepMS	Normal
There's no real code to speak of, it's all in the C++ stuff, can't walk it up the process any.

Console:
[quote]06:24:08.181 E Net Unhandled opcode 0x000004CA (1226) from 87.58.115.153
06:26:13.190 I Chunk Shutdown timer expired. Shutting down Tursh Village.
06:28:41.735 D Char Saving character 'Dali Lightbringer' (924)
06:28:43.364 D Char Saved successful for character 'Dali Lightbringer' (924)
06:33:41.735 D Char Saving character 'Dali Lightbringer' (924)
06:33:44.541 D Char Saved successful for character 'Dali Lightbringer' (924)
06:38:41.739 D Char Saving character 'Dali Lightbringer' (924)
06:38:41.759 D Char Saved successful for character 'Dali Lightbringer' (924)
06:39:15.147 W Chunk Stub behavior for handling OP_ClientAccessObject with race_id ='754'
06:39:15.338 W Chunk Stub behavior for handling OP_ClientAccessObject with race_id ='754'
06:40:21.126 D Database Vendor id = 1.
06:40:43.888 D Database Vendor id = 6.
06:41:08.938 D Database Vendor id = 6.
06:42:00.078 D Database Vendor id = 8.
[/quote]