Changes between Version 3 and Version 4 of Debugging


Ignore:
Timestamp:
Sep 13, 2013, 8:24:06 PM (11 years ago)
Author:
historic_bruno
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Debugging

    v3 v4  
    5454=== Call stack on Windows ===
    5555Reading `crashlog,dmp`:
    56 * It can be opened in Visual Studio or !WinDbg. For this to be useful, '''you need to have the debug symbols and source code matching the affected build of the game'''. Most users use the autobuild version of the game, you can simply download the correct autobuilt binaries from SVN. Or for a release, install that particular version of the game and acquire source packages from [http://releases.wildfiregames.com/]. In the future we could automate this process, see #290.
     56* It can be opened in Visual Studio or !WinDbg. For this to be useful, '''you need to have the debug symbols and source code matching the affected build of the game'''. Most users use the autobuild version of the game, you can simply download the correct autobuilt binaries from SVN. Or for a release, install that particular version of the game and acquire the matching source package from [http://releases.wildfiregames.com/]. In the future we should automate this process, see #290.
    5757* You also need to set up symbol paths and a cache location for Microsoft symbol server, see [http://support.microsoft.com/kb/311503 Use the Microsoft Symbol Server to obtain debug symbol files].
    5858* In Visual Studio, after setting up your debug symbol paths, open the `crashlog.dmp` and choose to debug natively. You should get a crash of some kind, then you can break into the debugger. The call stack window will show you which functions were being called at that point. Note that in release builds, some data will be optimized out and not easily viewable.
    … …  
    7777
    7878Out of sync (OOS) and serialization errors are generally difficult to debug, but knowing where to look can make this process simpler. An OOS error occurs in a multiplayer game when one player's serialized simulation state isn't identical to another player's serialized simulation state (breaking the concept of network synchronization). The following data are useful to collect in this case:
    79 * `oos_dump.txt` - a human readable snapshot of the simulation state at the point of OOS, created for each player in the game. Found in the logs folder, see GameDataPaths.
     79* `oos_dump.txt` - a human readable snapshot of the simulation state at the point of OOS, created on each player's computer. Found in the logs folder, see GameDataPaths. Each player should zip these files and send them to the person troubleshooting the bug.
    8080* Each player's game version - these have to match, while the game is in alpha phase the simulation changes constantly and there is no backward compatibility. For releases, it means using the same alpha release, for SVN users, it means using the same SVN revision (with few exceptions).
    8181* OS and hardware info for each player (`system_info.txt`) - Some serialization bugs are platform specific, so knowing the systems involved is key to reproducing the error.
    … …  
    9191
    9292The following are known, reproducible causes of OOS errors:
    93 * Rejoining a multiplayer game with AIs - because the AIs don't fully serialize their state, the rejoining player's state will differ and cause an OOS.
    94 * Multiplayer games with Aegis AI
     93* Rejoining a multiplayer game with AIs - because the AIs don't fully serialize their state, the rejoining player's state will differ and cause an OOS, see #1089.
     94* Multiplayer games with Aegis AI, see #2000.
    9595
    9696=== Serialization test mode ===