[salamanda]

Is there a major difference between the crash dumps in release and debug mode now that you have reverted the commit that disabled crash dumps in release?

The reason I ask this, is because I would like to support ArcEmu by submitting any crashes that occur, but when the server is built in debug, a crash can cause a message box to open asking whether to abort, retry or ignore. Whichever option you pick, it then logs the crash dump and shuts down (and starts back up with a auto-restarter). The issue with this is that the server hangs until a option is picked, which can cause long periods of downtime until I get on and respond to it.

If I am able to submit crash dumps in release mode then I can run the server normally without having to worry about possible downtime. However, if a release mode crash dump is not very useful then I will keep using debug mode.

[dfighter]

There is. The best we can hope for in release mode is a callstack, since the values are optimized out. ( and it also often crashes too late, not where the problem is, as many things are not even checked )
In debug values are preserved and there are lots of checks so it crashes right where the problem is ( usually anyways ) so it's easier to track the issues down.
The reason why we re-enabled this is simply that we plan on having more official binary package releases and in a more orderly fashion, but we can't release debug builds, since you can only run that on a machine that has visual studio installed ( the debug libraries cannot be redistributed either technically or legally ), but we'd still like to be able to get at least some feedback about crashes, even if they are a lot harder ( if not impossible ) to sort out.
So if you can, just continue using debug mode
Thanks!

[jackpoz]

salamanda, on 27 August 2011 - 06:22 PM, said:

but when the server is built in debug, a crash can cause a message box to open asking whether to abort, retry or ignore.

I think it's time for us to read more about http://msdn.microsof...ibrary/1y71x448 qnd properly use it to disable those pop ups. In that way you'll not have to worry anymore about downtimes

[salamanda]

Okay, thank you both for the reply.

[jackpoz]

salamanda, on 27 August 2011 - 06:22 PM, said:

but when the server is built in debug, a crash can cause a message box to open asking whether to abort, retry or ignore.

No messages will pop up anymore after r4501 https://sourceforge..../changeset/4501

[salamanda]

Haha, brilliant. Thanks again.

edit:

Actually the new commit doesn't solve that problem.

Now it says "world.exe has stopped responding" and it hangs till you click "close this program". =/

Also no crash dump is created now.

[jackpoz]

can you post the last lines of the logs, so we get an idea of why it crashed?
You should also disable WER (Windows Error Reporting).

[salamanda]

Windows error reporting is already disabled.

Will post last few log lines, but I have to wait for it to crash again. Will update this post when it does.

When message box comes up saying it has stopped responding -> Log shows:

[10:38] [ArcEmu]  [ERR] C:\Users\Harry\Desktop\Kronos Update\src\arcemu-world\Object.cpp:1536 Object::_setFaction Unit does not have a valid faction. It will make him act stupid in world. Don't blame us, blame yourself for not checking :P, faction 0 set to entry 17280
[10:39] [ArcEmu] Sql query failed due to [Duplicate entry '484-2' for key 'PRIMARY'], Query: [INSERT INTO playerpets VALUES('484','2','Derp','17280','0','11','19','117440514 0,117440513 0,117440512 0,17256 49408,64491 49408,14916 49408,0 0,100663298 0,100663297 0,100663296 0,','4614','0','0','0','1','1','0','100','932','944160','0','1')]
[10:39] [ArcEmu]  [ERR] C:\Users\Harry\Desktop\Kronos Update\src\arcemu-world\Object.cpp:1536 Object::_setFaction Unit does not have a 

So it cancels out halfway through printing.

No crash dump is created since I applied that rev which removed the abort/retry/ignore message box. Though I'm guessing it's a Lua engine crash, since about 30 seconds before it frooze, all Lua scripts just stopped registering new functions.

[jackpoz]

try to apply

Index: src/arcemu-shared/CrashHandler.cpp
===================================================================
--- src/arcemu-shared/CrashHandler.cpp	(revision 4501)
+++ src/arcemu-shared/CrashHandler.cpp	(working copy)
@@ -88,10 +88,13 @@
 
 	if(!ON_CRASH_BREAK_DEBUGGER)
 	{
+		_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE );
+		_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDERR );
 		_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE );
 		_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDERR );
 		_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
 		_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
+		SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
 	}
 }

also what's the behaviour of http://archive.msdn....DownloadId=9679 sample?

which Visual Studio version are you using?

[salamanda]

I'm using Visual C++ Studio 2010 Express.

I'm a bit confused as to what you want me to do with the project you linked, I compiled it and ran it on the dedi and this was the result:



I have applied the patch and am awaiting for the server to crash again.

[jackpoz]

I linked that project to see if it would hang with the "has stopped responding" error message.

[salamanda]

Well, it didn't.

[jackpoz]

Looks like the usual dfighter&jackpoz Ltd found another Lua issue:
right now all projects are built with /EHsc flag

but according to msdn http://msdn.microsof...y/1deeycx5.aspx

Quote

If used with s (/EHsc), catches C++ exceptions only and tells the compiler to assume that extern C functions never throw a C++ exception. /EHca is equivalent to /EHa.

Now, do we know any extern C function? OFC!!!
trunk\src\scripts\src\LuaEngine\LUAEngine.h

extern "C"
{
	// we're C++, and LUA is C, so the compiler needs to know to use C function names.
#include "../lualib/lua.h"
#include "../lualib/lauxlib.h"
#include "../lualib/lualib.h"
};

now, let's guess, will these throw any C++ exception? Silly me, it's just so obvious.
trunk\src\scripts\src\lualib\luaconf.h

#if defined(__cplusplus)
/* C++ exceptions */
#define LUAI_THROW(L,c)	throw(c)

so, we first tell the compiler that "that extern C functions never throw a C++ exception" and then throw them? this feels like trahison!

Stay tuned on our trac to see when we will set the right flag to cmake, then remove the patch I posted and try again.

[salamanda]

Haha, Okay. Thanks.

[jackpoz]

try latest rev (r4504), cmake should recreate the project files automatically from VS (I had to stop the build and start it again after it recreated the projects) and then tell if you still get the "stopped responding" popup message.