Linux GDB Debugging
From Project Skyfire
GDB: The GNU Project Debugger.
Original Author is Derex from the MaNGOS project. http://getmangos.com/community/topic/4579/howto-gdb-debugging/
Hi, this is a simple/dirty tutorial of what is GDB and how to use it.
This tutorial assumes that you can start your worldserver by typing:
in the console.
1. Before you start debugging SkyFire you need to have ensured that it is compiled with debug information. To build SkyFire with debug info just add --with-debug-info to your options when running ../configure. Then compile and install SkyFire as usual.
2. Now you can start SkyFire with gdb by typing this.
Then you will most likely see something like this:
derex@*:~/workspace/SkyFire/build$ gdb worldserver GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... (gdb)
(gdb) - is the GDB command prompt smile , here you can type some commands, almost like in normal shell.
Now after you have gdb running, you may instruct it to start SkyFire ( by having gdb start SkyFire you can debug it ), here is the command:
Just type it and if you are lucky you will have SkyFire loading.
Ok ... you made it, now SkyFire runs. Take a break until it crash ,then you can come back smile
3. When SkyFire crashes you will most likely see this message, or any similar.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42c5c950 (LWP 9283)] Player (this=0x42c598e0, session=0x0) at ../../../src/game/Player.cpp:265 265 ../../../src/game/Player.cpp: No such file or directory.
Now you can type some commands to get information about the crash, and possibly give it to some dev to fix the problem.
Here are the commands that are best to be typed ( or at least I find the most useful for crash report )
shell echo -e "\nCRASH ON" `date` info program shell echo -e "\nBACKTRACE\n" bt shell echo -e "\nBACKTRACE FULL\n" bt full shell echo -e "\nTHREADS\n" info threads shell echo -e "\nTHREADS BACKTRACE\n" thread apply all bt full
Just type them one after another and give the output in your bug report ...
OK. That is it, now we can think of some way to automate all this process. GDB has 2 very good switches:
--batch Exit after processing options. --command=FILE, -x Execute GDB commands from FILE.
4. So you can put all the commands in one file and have GDB execute it, and when it finishes to exit. Lets say we put this in one file called gdb-commands.
run shell echo -e "\nCRASH ON" `date` info program shell echo -e "\nBACKTRACE\n" bt shell echo -e "\nBACKTRACE FULL\n" bt full shell echo -e "\nTHREADS\n" info threads thread apply all bt full
Now you can start the whole monster with:
gdb worldserver --batch -x /path/to/gdb-commands
TIPS 1.You can also redirect stdout to some log file. I mean this:
gdb worldserver --batch -x /path/to/gdb-commands > /some/log/file
2.You can add a tail command to gdb-commands file to get the latest lines from your server.log file:
shell echo -e "\nSERVER.LOG\n" shell tail -n 50 /path/to/your/server.log
50 means how much lanes to take from server.log
3. You can add -ggdb3 -g3 flags to your CXXFLAGS in order to get more debug output. If you add them there is no need to add --with-debug-info switch in order to get meaningful back-trace.
4. You can pass arguments to worldserver by passing them to the run gdb command ( run -c /path/to/worldserver.conf ).
To get correct version information about SkyFire ( so no need to specify it in the bug report ... its already there and its correct, and you can't forget it ).