![]() ![]() gdb should give you a prompt, at which you can type the command, This should run gdb, and print out alot of information which is generally of no consequence (unless there is an error message). To open it, you run gdb giving it the path to the Wesnoth binary as its first argument, and the core file as its second. Now that you have your core, you can open it and see where Wesnoth crashed. You can of course list all cores in the current directory using, ![]() The core file will then be in the current working directory, and will either be called 'core' or 'core.' where is the process ID of Wesnoth before it crashed. The last line of output should be something like, Then, run Wesnoth, and do whatever you have to do to make it crash. So, before running Wesnoth, use the following command in the same terminal you plan to run Wesnoth from to make it so that cores will be always dumped, no matter how large they are. However, many systems by default have the maximum size of cores set very low, or to 0, meaning that the system won't dump cores. A 'core' file contains the contents of memory at the time the program crashed. When a program crashes, if the system is configured correctly it will leave behind a 'core' file. Even a non-programmer can do enough to give a developer alot of clues about where Wesnoth is crashing. A common problem is that a user of Wesnoth has Wesnoth crash on them, but no developers can reproduce the problem, and so that makes it very difficult for us to fix it.įortunately, if you are using GNU/Linux or another Unix-like system, have compiled Wesnoth yourself, and you have debugging symbols in (the default when compiling), or your packager has left debugging symbols in, you can do a little debugging yourself to send to a developer.
0 Comments
Leave a Reply. |