Client Crashes During Mission Load Phase 2
by Scott Doerrfeld · in Torque Game Engine · 06/28/2007 (11:39 am) · 2 replies
I am running a remote dedicated server that I compiled for Linux (TGE 1.5.2). The Linux build compiled without any errors. Now I am trying to connect to that server from my Windows machine. Well the connection gets established and the Mission Load sequence gets through Phase 1 (datablocks) just fine. Then, the client crashes just as Phase 2 (ghost objects) gets acknowledged by the server. This happens regardless of what mission file is loaded. On the server side, it doesn't crash. It just eventually logs the client out after a while of not detecting the connection.
I am pretty sure it has something to do with the %client.activateGhosts() function that gets called on the server side (missionDownload.cs). Running the client thru the debugger indicates some memory error involving the hdr->treeNode() pointer.
This memory stuff is a bit over my head. I didn't have this problem with TGE 1.5.1. What could be going wrong?
NOTE: Running both the client/server on my Windows machine works fine. It is just a problem with my Linux build.
I am pretty sure it has something to do with the %client.activateGhosts() function that gets called on the server side (missionDownload.cs). Running the client thru the debugger indicates some memory error involving the hdr->treeNode() pointer.
This memory stuff is a bit over my head. I didn't have this problem with TGE 1.5.1. What could be going wrong?
NOTE: Running both the client/server on my Windows machine works fine. It is just a problem with my Linux build.
About the author
Torque 3D Owner Stephen Zepp
To briefly describe the process, when your projects are compiled on the respective operating systems, each builds a table of AbstractClassReps so that objects can be remotely instantiated across the network onto other computers, optionally on different operating systems. For every class that uses one of the DECLARE_XXXOBJECT macros, it notes an ordered index number (the AbstractClassRep), and the specific compiled code for that OS that is associated (the ConcreteClassRep).
Since this is an ordered table, if your projects do not compile these classes in order, the AbstractClassRep "9"on your linux machine (for example) may point to the Player class, yet on your windows machine it points to the Vehicle class.
When the ghosting system attempts to remotely instantiate an object of ACR "9", the client has the wrong type of object to create, and then when it tries to populate the object with the ghosted data, it violates memory constraints (commonly) and causes a crash.
A year and a half ago or so someone came up with some troubleshooting code that reports the AbstractClassRep table and what classes it points to, which can help you figure out which objects are compiled out of order--try searching for some of the key words I used above to see if it helps.
You may also want to review what code changes you've made (obviously there is at least a merge there from 1.5.1 to 1.5.2, plus any new resources/changes you may have made yourself), and manually check your makefile and windows project file to determine any compilation order issues.