Jump to content
TrinityCore
Rochet2

Tutorial for debugging, crashlogs, edit and continue

By Rochet2, in Guides

Recommended Posts

Rochet2    206

Rochet2
Posted

A lot of people have asked how to debug so I made this short guide on how to set up debugging. This will not explain the basics of debugging. You can google those or play around with the debugger to learn.
There are guides for Linux and Windows. (though linux is not as detailed)
This guide contains multiple guides. Each list of bullet points is it's own guide.

Make sure you can run the server normally before trying to debug.

On Windows before anything you should check these
- Before debugging or making crashlogs etc. with Visual Studio you must compile the core in "Debug" instead of "Release". You can select this in "Build>Configuration Manager" or at the top of Visual Studio window http://i.imgur.com/5oHd59j.png
- You also need to move the new pdb files generate by compiling in debug mode on Visual Studio from the compile output folder (bin) to your server folder - these files contain information needed for debugging.
- It is assumed that Solution Explorer is open. Open it by selecting "View>Solution Explorer" in Visual Studio http://i.imgur.com/hkW6Gk0.png
-- You may want to click on the Home icon to reset the view on Solution Explorer http://i.imgur.com/N8UPwDh.png
- You can place breakpoints in Visual Studio editor by right clicking a line of code and selecting "Breakpoint>Insert Breakpoint" http://i.imgur.com/L2TxBVG.png
- At the top of the window you should see controls for stepping and continuing when you have started to debug.
- Here is a video showing the basic Visual Studio functionality https://www.youtube.com/watch?v=Ijdk4z8-2OI

First off we go with the fastest way to debug on windows. This is the easiest way to start up debugging a script.
- Start the authserver and worldserver normally
- Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core
- In Visual Studio at the top select "Debug>Attach to process...>worldserver.exe" and click "Attach" http://i.imgur.com/jDEI2Hq.png
- You are now debugging

 

The second slower way of debugging on windows. This is useful for debugging something that occurs in the startup of the server.
- Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core
- In solution explorer right click on worldserver and select "Set as StartUp Project" http://i.imgur.com/wvMzeRA.png
- In solution explorer right click on worldserver and select "Properties" http://i.imgur.com/rTNEF9O.png
-- In Properties you should go to "Configuration Properties>Debugging" and edit "Working Directory" to point to the server folder. For me this is the default compile folder so I use "$(OutDir)" http://i.imgur.com/aRI29fB.png
- Start the authserver normally
- Start the worldserver by selecting "Debug>Start Debugging". The server will start with debugging attached from the beginning http://i.imgur.com/cg1KJNw.png
- You are now debugging

Crashlogs on windows. Once you have a way to reproduce a crash you can get a crashlog that can help you resolve it.
- After compiling the core in "Debug" instead of "Release" start up the worldserver and authserver
- Reproduce the crash you have
- In the server folder there is now a folder called Crashes that contains txt and dmp files. http://i.imgur.com/9eQIdql.png
- You can open the txt files in text editors http://i.imgur.com/EH6R17E.png
-- At the top of a txt file there is some information about your system and below it there is the Call Stack and below that there are Variables of each part of the call stack
-- The Call Stack will tell you at the top what was the last function call before crashing and what function calls led to that function call.
-- Next to the function names there is the file that the function is defined in and the line number the code was executing in that function.
-- In the Variables section you can inspect variables that were present at each function call.
-- Based on this information you are often able to see what crashed or get a better view of what you need to inspect more in your code.
- The dmp file can be opened in Visual Studio
-- Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core
-- Drag and drop the dmp file to Visual Studio
-- In the window that opens click to "Debug with Native Only" http://i.imgur.com/OgyU2kM.png
-- In the window popup click "Break" http://i.imgur.com/4jDzqRn.png
-- You are now in a state like you would have hit a break point in the code or a crash while debugging. You can inspect the call stack and the variables.

Edit and continue on windows. When debugging this allows you to change the code and without restarting the server apply those changes so they actually work ingame.
- Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core
- In solution explorer right click on worldserver and select "Properties" http://i.imgur.com/rTNEF9O.png
-- In Properties select "Configuration Properties>Linker>General" and set "Enable Incremental Linking" to "Yes". http://i.imgur.com/caQqwN5.png
-- In Properties select "Configuration Properties>Linker>Advanced" and set "Image Has Safe Exception Handlers" to "No". http://i.imgur.com/FYzN8Ks.png
-- In Properties select "Configuration Properties>C/C++>General" and set "Debug Information Format" to "Program Database for Edit And Continue". http://i.imgur.com/pxQ6I8N.png
- At the top of the window select "Tools>Options". In the Options select "Debugging>General" and in there select "Enable Edit and Continue", "Enable Native Edit and Continue" and "Require source files to exactly match the original version".
- Compile the server for the changes to take effect.
- Set up "The second slower way of debugging" (I did not test edit and continue on other configurations)
- Start the authserver normally
- Start the worldserver by selecting "Debug>Start Debugging".
- Try edit a cpp file a little and save it.
- At top of Visual Studio window select "Debug>Apply Code Changes" and wait until the changes are applied. Warning: it can take considerable amount of time for the changes to be applied. http://i.imgur.com/77pb58E.png
- If you have issues, be sure to check the error messages in Output. You can view it by selecting "View>Output" http://i.imgur.com/4cIznW9.png
- This guide was written based on https://msdn.microsoft.com/en-us/library/esaeyddf.aspx and https://blogs.msdn.microsoft.com/vcblog/2015/07/22/c-edit-and-continue-in-visual-studio-2015/

Debugging on linux. You can debug on linux by using GDB.
- Here is a good video about it: https://www.youtube.com/watch?v=sCtY--xRUyI
- Basically you
-- Start the authserver
-- Start the worldserver by using "gdb ./worldserver"
-- Enter breakpoints by using break command on gdb
-- Use the run command on gdb to start the server
-- You are now debugging
- You may also be interested in using VScode or some other more visual debuggers. https://www.youtube.com/watch?v=B0xTgyCwsAo

Crashlogs on linux. Once you have a way to reproduce a crash you can get a crashlog that can help you resolve it.
- Compile the server with the cmake flag -DCMAKE_BUILD_TYPE=Debug
- Take crashreport.gdb from /contrib/debugger from source folder and place it to your server folder
- Start the authserver
- Start the worldserver by using "gdb -x crashreport.gdb ./worldserver"
- Reproduce your crash
- There should be a backtrace.log in your server folder that contains information about the crash like the callstack and variables in each function call in the call stack
- This guide was written based on https://github.com/TrinityCore/TrinityCore/blob/master/contrib/debugger/README

Running valgrind on linux. This helps you find memory errors like invalid reads and writes and memory leaks.
- Here is a good video about it: https://www.youtube.com/watch?v=fvTsFjDuag8
- Basically you
-- Start the authserver
-- Start the worldserver by using "valgrind ./worldserver"
-- Run your code that you want to analyze and close the server
-- The console or an output log should contain the valgrind log

  • Upvote 5

Share this post

Link to post
Share on other sites

Shauren    168

Shauren
Posted

You are telling people to enable incremental linking but it is disabled on purpose because in some cases the linker just gets stuck and never finishes when building Debug (which is the point of debugging)

  • Upvote 1

Share this post

Link to post
Share on other sites

Rochet2    206

Rochet2
Posted
30 minutes ago, Shauren said:

You are telling people to enable incremental linking but it is disabled on purpose because in some cases the linker just gets stuck and never finishes when building Debug (which is the point of debugging)

Debugging does not require incremental linking, so if someone has issues with that they should disable it. Incremental linking is required by edit and continue however. So if the build gets stuck then you cannot use edit and continue and should disable incremental linking.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Go To Topic Listing

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • vladex
      TrintyCore full programming guide.
      By vladex
      Hello,
       
      I've been gone for a good while from wow and from wow emulation. I'd like to at least try to learn more about the tc code in general, is there any proper documentation from top to bottom that describes the packages, libraries and API used in the TC code ? I find the guide on atlassian a bit short.
       
      Thank you.
    • Ramboknife
      Debugging in Linux with VSCode + GDB?
      By Ramboknife
      So I'm trying to set up a debugging process where I can see what functions are being called when I do certain things in game, that way I can hopefully locate exactly which functions in which cpp files might possibly be involved with the bug I'm trying to fix.  Is something like this possible?  I can get VS Code to launch my worldserver or attach to the worldserver process but beyond that I'm not getting any other information out of the Call Stack or anything when I make certain actions in-game.
      Thanks
    • Taaboy
      A guide to Spawndist(To be more Blizlike)
      By Taaboy
      A guide to Spawndist(To be more Blizlike)   By TAABOY (DEC-2016)   This is written for the people that are trying to find or experiment with the movement of creatures in the world for EMU WOW. With countless database backup reloads, and reading all information available on the net, with many different types of EMU's. I have summerized data, this is my opinion the best way about going about it. From this moment forward , following meaning will be used in this guide.
      Mobs = NPC/Creatures
      NPC = Guards / Trainers / Vendors / Questgivers.
      Creatures = all other mobs (including all other killable open world humaniods).
       
       The meaning of Spawndist in relation to wow emu's ,it is the distance the Mobs moves away from its original spawn location, so to make it more blizlike instead of statue like Mobs in the emu world , we add some movement. To do this we have to add a value to the creature table(spawnDist) and (Movementtype) . We can just go blanket sql on all the Mobs, but i have found that can cause massive problems for nearby/limited space or named/patrol Mobs. Can be said that blanket entry in creature table for certain creature id entry is possible if limited to 5 or 10 yard radius ,but only after checking that you are not going to stuff up entries that have waypoint attach creatures with the same creature id entry in the creature table. There are exception to everything but waypoints is a different subject and not covering this here.
       
       Creature Table:
       Spawndist = 1 to 100 Yards.
       Movementtype = 0(Standstill) 1 (Random movement inside the spawndist radius) 2(Waypoint Movement) .
       
       Creature_Template Tables:
       InhabitType = 0(Ground) 2(Water/Swim) 4(Flying) 8(Rooted)
       Hoverheight = Distance From spawned location height ,effects mostly flying mobs ,Setting 1/2/3 in table. (example = Vulture flying in the air instead of flying along the ground), (More Data required for Flying NPC Patrols).
       Movementtype = (Don't Play with it unless you know what you are doing, as this is supposing to set all entries of that creature to override the setting in creature GUID).
       
       More Details can be found here https://trinitycore.atlassian.net/wiki/display/tc/creature_template
       
       
       Recommended for Novice's don't play with the NPC movement's, some have waypoints and you will stuff them up and if you complain to the DEV's they are not going to help you.
       
       So to make this easy, it is best that you make some macro's and mount up ride around to every creature and set spawndist manually for the locations that they reside to and not to break creatures that have waypoints attach to them.
       
       macro command : set different distances for example:
        .npc set spawndist 5
       
       People have asked me to put up the spawndist that i have done for most of my Cata world but then realised that all EMU's are different and Version of release's with different GUID's in the creature table of the database. So i have written this guide to help the others out there to do this for themselves in game for the novice and with some entries into the database if required for the more knowledgeable.
       
       For additional information not covered or want to add, please comment and if you want to RANT B.S you have the right too but back up your comments.
       
       IMPORTANT INFORMATION BACKUP YOUR DATABASE BEFORE DOING ANY CHANGES.
       IMPORTANT INFORMATION BACKUP YOUR DATABASE BEFORE DOING ANY CHANGES.
       IMPORTANT INFORMATION BACKUP YOUR DATABASE BEFORE DOING ANY CHANGES.
       
       Thank you for reading
       TAABOY
       
       
       P.S Also like to thank the people out there that i have read some information from, but as this information i have read is up to 3 to 5 years old i can't say they are still active.
×
×
  • Create New...