Random client crash
by Howard Dortch · in Torque 3D Professional · 04/04/2015 (10:58 am) · 19 replies
Version 3.16 I have an rpg using a dedicated server. The server sends periodic data to each client like food and water levels etc. There are times when the client mouse clicks an object, sends message to server, decides which object is being accessed and the server sends a interact message back to client to open a dialog.
The game runs extremely slow in debug and it never crashes.
So here is the question:
Can the client receive multiple messages at the same exact time?
Is there a preferred way to message clients like have the server stack messages in a cue?
Seems the messaging is causing the crash since it only happens trying to select objects.
Any help?
The game runs extremely slow in debug and it never crashes.
So here is the question:
Can the client receive multiple messages at the same exact time?
Is there a preferred way to message clients like have the server stack messages in a cue?
Seems the messaging is causing the crash since it only happens trying to select objects.
Any help?
#2
a thing will surely help would be to run the game in the debugger to know exactly what happens and where it happens.
04/11/2015 (5:10 pm)
it's difficult to tell without the code, but if I can give a clue, make sure you are not changing any datablock on client or server only:a thing will surely help would be to run the game in the debugger to know exactly what happens and where it happens.
#3
I put echo statements all over the code and neither client or server gives me an indicator of what happens at time of crash and it never crashes in the same place.
Socket not stacking a message cue, threading not getting semaphores or something.
04/12/2015 (7:59 am)
No datablocks are being changed on server or client and as I said in the first post the game runs so slow in debug like 1 frame per sec or less so debug will not help. I ran it for 4 hours one day in debug and no crashes which leads me to think it's a message timing issue.I put echo statements all over the code and neither client or server gives me an indicator of what happens at time of crash and it never crashes in the same place.
Socket not stacking a message cue, threading not getting semaphores or something.
#5
04/12/2015 (8:27 am)
And enable crash dump? Might help, not entirely sure on that though.
#6
how would I enable crash dump? You mean the windows info?
Last time I looked it was the oxc00005 thing with a null pointer
thanks for the reply
04/12/2015 (2:00 pm)
no_debug_heap in the engine?how would I enable crash dump? You mean the windows info?
Last time I looked it was the oxc00005 thing with a null pointer
thanks for the reply
#7
It is supposed to generate a crash dump that Visual Studio can load up so you can debug with the exact state at crash time.
Whether this still works or not is unknown.
04/12/2015 (6:53 pm)
In project.conf uncomment:addProjectDefine( 'TORQUE_MINIDUMP' );Then regenerate your projects.
It is supposed to generate a crash dump that Visual Studio can load up so you can debug with the exact state at crash time.
Whether this still works or not is unknown.
#8
(google for no_debug_heap=1 )
You can also compile in release build with debug symbols!
04/13/2015 (4:55 am)
no_debug_heap in the debugger options in visualstudio. (google for no_debug_heap=1 )
You can also compile in release build with debug symbols!
#9
// Configure Torque 3D
Torque3D::beginConfig( "win32", "Frontier" );
// Include Web Deployment module
// Enable for optional minidump debugging support
addProjectDefine( 'TORQUE_MINIDUMP' );
It crashed but I can't find where the dump would be. Supposed to be in root directory of the game?
04/13/2015 (2:27 pm)
Added this in project.conf and did a full rebuild// Configure Torque 3D
Torque3D::beginConfig( "win32", "Frontier" );
// Include Web Deployment module
// Enable for optional minidump debugging support
addProjectDefine( 'TORQUE_MINIDUMP' );
It crashed but I can't find where the dump would be. Supposed to be in root directory of the game?
#10
It works as this:
launch the game compiled in release build with debug symbols on and configured to be loaded, reproduce your crash, you have the call stack ready for you to see what happens and where it happens.
04/13/2015 (3:35 pm)
I never used torque's minidump but I really recommend to follow the suggestion I already gave you: with that method I succesfully tracked down and fixed tons of crashes who appeared on release build only.It works as this:
launch the game compiled in release build with debug symbols on and configured to be loaded, reproduce your crash, you have the call stack ready for you to see what happens and where it happens.
#11
From the source,
Hopefully it did what it is supposed to do, but I guess we'll find out when you read this.
04/13/2015 (3:49 pm)
Hell, I don't know - I already said I don't know if it even still works....From the source,
//Build a Game, Date and Time stamped MiniDump folder
time_t theTime;
time(&theTime);
tm* pLocalTime = localtime(&theTime);
char crashFolder[2048];
dSprintf(crashFolder, 2048, "%s_%02d.%02d_%02d.%02d.%02d",
Platform::getExecutableName(),
pLocalTime->tm_mon+1, pLocalTime->tm_mday,
pLocalTime->tm_hour, pLocalTime->tm_min, pLocalTime->tm_sec);however, I am able to deduce that it creates a folder named game_month.day_hour.min.sec and tries to put the dump there....Hopefully it did what it is supposed to do, but I guess we'll find out when you read this.
#12
04/14/2015 (6:03 pm)
In order to compile with MiniDump support, you need to make sure TORQUE_RELEASE is defined as well. Open up the DLL's pre-processor definitions while in release mode and make sure that TORQUE_RELEASE is in the list, otherwise its not being compiled into the DLL.
#13
Here is where it crashed
IMPLEMENT_CALLBACK( GuiControl, onActive, void, ( bool state ), ( state ),
First-chance exception at 0x00000858 in Frontier.exe: 0xC0000005: Access violation reading location 0x00000858.
Script where I assumed it hit
function ToteBoxDlgUse()
{
$MovementSpeed = 0;
Canvas.pushDialog(ToteBoxDlg);
}
05/08/2015 (6:55 am)
Finally pushed enough buttons to get the debug info in release.Here is where it crashed
IMPLEMENT_CALLBACK( GuiControl, onActive, void, ( bool state ), ( state ),
First-chance exception at 0x00000858 in Frontier.exe: 0xC0000005: Access violation reading location 0x00000858.
Script where I assumed it hit
function ToteBoxDlgUse()
{
$MovementSpeed = 0;
Canvas.pushDialog(ToteBoxDlg);
}
#14
I tracked the crash down to what seemed like it was in the loading portion of the code for the image, but I'm not 100% certain.
05/08/2015 (7:07 am)
I've seen a crash come from opening a GUI before as well. My GUI was solely a GUIControl with an image as the only other element. I was using the GUI as a sniper scope overlay. The image was a PNG exported from photoshop using the SuperPNG format.I tracked the crash down to what seemed like it was in the loading portion of the code for the image, but I'm not 100% certain.
#15
One more bit of info. This gui is an inventory routine where the user clicks a button and gets an inventory item. I set the buttons inactive so they can't hammer them too fast. I have a schedule(400,0,resetButton) in every case where the crash happens.
Using a delay schedule to set the buttons active may be an issue.
Anyone ?
05/08/2015 (8:27 am)
@Adam thanks.One more bit of info. This gui is an inventory routine where the user clicks a button and gets an inventory item. I set the buttons inactive so they can't hammer them too fast. I have a schedule(400,0,resetButton) in every case where the crash happens.
Using a delay schedule to set the buttons active may be an issue.
Anyone ?
#16
with this method you can set a boolean in the button property to use or not the debounce and how many milliseconds to delay without using the schedule on the script side.
IMHO is the more elegant way to do that.
05/08/2015 (10:55 am)
I suggest to make a clone of the button control and setting your debounce delay in c++. for an example of a delay you can look at guiFadeInBitmapCtrl.with this method you can set a boolean in the button property to use or not the debounce and how many milliseconds to delay without using the schedule on the script side.
IMHO is the more elegant way to do that.
#17
05/08/2015 (1:50 pm)
I'll take a look at doing that. In the mean time still not sure if this is the culprit that causes the crash.
#18
Another method to do the debounce would be inside of:
function myButton::onClick() you get the milliseconds from the engine (something like getSimTime())
and do something like:
you can put the delay in the button fileds in the .gui as delayVal = 500; and then get it with for example myButton.delayVal
I hope will be useful!
05/08/2015 (2:41 pm)
don't you have the callstack? if you have compiled a release build with debug symbols, you should be able to attach the VisualStudio debugger and see the callstack. Another method to do the debounce would be inside of:
function myButton::onClick() you get the milliseconds from the engine (something like getSimTime())
and do something like:
myButton::onClick(%this)
{
%theValueToDelay = 500; //this should be in mybutton.delayVal
if(%this.lastTime == 0)
%this.lastTime = getSimTime();
if(getSimTime() > ( %this.lastTime + %theValueToDelay ) ) //if the current time
//is greater than the last time plus the delay we put
{
//do your stuff here
%this.lastTime = getSimTime(); //reset the value
}
else
return; //or something else
}you can put the delay in the button fileds in the .gui as delayVal = 500; and then get it with for example myButton.delayVal
I hope will be useful!
#19
if( getNamespace() ) // May be called during construction.
onActive_callback( value );
this = null pointer at the crash
The callback seems to be setting a bool active but it is already set a few lines before that so I am not sure why the callback.
I comment those 2 lines out and havent had a crash since.
So someone explain why the callback is necessary and how getNamespace returns a null and voids the if statement.
Another question on dialogs should every item in the dialog be named?
Thanks for all the replies.
05/10/2015 (6:45 am)
The crash always happens here GuiControl.cpp line 1718if( getNamespace() ) // May be called during construction.
onActive_callback( value );
this = null pointer at the crash
The callback seems to be setting a bool active but it is already set a few lines before that so I am not sure why the callback.
I comment those 2 lines out and havent had a crash since.
So someone explain why the callback is necessary and how getNamespace returns a null and voids the if statement.
Another question on dialogs should every item in the dialog be named?
Thanks for all the replies.
Torque 3D Owner Howard Dortch
Default Studio Name