Jump to Main Content

Debugging Tips

When reporting bugs please use SourceForge Bug Tracker, or if you need to report a bug to the mailing list, be sure to included the following:

    1. What version of Crossfire you are running. (This can be checked in game with the command, 'version)

    2. What component of Crossfire you have found a bug with. To name a few:
      • Archtypes - this includes item or monster or object stats, abilities, animations, etc.
      • Au-sounds
      • Documentation - any instructions or game details written on the website, wiki or README information included with the game
      • GTKv2 client - one of the game clients
      • Gridarta - map editor
      • Images
      • Jxclient - one of the game clients, based on Java
      • Logger - in game feature to track and record certain actions and events
      • Maps - in game content that players interact with
      • Object Scripts
      • Raw Sounds
      • Server - code that basically runs the game

    3. What OS you are running and release info, if applicable. (For instance, Windows 7 or Ubuntu Lucid Lynx)

    4. A description of the bug that you have found.

Here are some additional tips from Mark Wedel, the Head Maintainer.

Give me access to a crossfire core file, and I'll investigate. Note that access typically means login to the system that the core was generated on. Given that, here are tips to make debugging for either myself or others more useful:

    1. By default, configure/autoconf use -g -O2 as compiler flags if it finds gcc. the -O2 makes debugging more difficult, as variables can get optimized out, execution is not necessarily in the same order, and so on. To get around this, I set my environment flags to "-ggdb" before running configure. You can in fact add that to your .cshrc/.profile, but then all programs will get that.

    2. Keep the core file with the tree that made it. If you have a core file from a few days ago and are about to do a svn update and recompile, copy the current compilation and put the core file with that. Trying to debug programs in which the core file does not match the executable is virtually impossible.

    3. Keep the log file that crossfire generates with the core file. The crossloop scripts already do this. Not always, but many times the log file may say why the program is exiting (this is typically if link lists are corrupted or it gets internally caught errors, vs something like memory scrambling and bad pointer derefs).

    4. Make sure you don't strip the binaries as you install them. By default, the installation does not do this, but you can just make sure that your executable (installdir/bin/crossfire) matches soucedir/server/crossfire). doing a size check is sufficient.

    5. Send me a stack trace. To do this: gdb executable core_file (ie, gdb /usr/games/bin/crossfire core), and then from within gdb do a 'where'. If you don't have gdb, install it as one can't do debug work without it. Also include the version of crossfire (including latest svn update). This information will at least let me quickly see where the crash happened, and will let me know if its a duplicate, and may even provide enough information to fix the problem.

I really want to get all these bugs squashed. Note that I can not promise I will always look at all cores - if some really widespread bug comes out such that there are core files all over the place, I'll just look at a few and once I figure out the problem, go from there.