Developing Freeciv
Coding Remember How to Contribute Bug Reporting Coding Style Commit Rules Source Tree Access Help Wanted Forum Known Bugs Browse Source Tree Testing Tips Release Process
v • d • e

To report a bug you should use our bug tracking system here. Before submitting a report you should check if the bug has already been reported. Take a look at the list of Known Bugs.

A good bug report should contain:

• Description of the problem. The easiest bugs to fix are those which developers can reproduce. If it is possible please provide a step by step instruction to trigger a bug.
• Freeciv version. Please specify how did you download or compiled your copy. If you report a problem in the client please tell us whether you are using gtk2, sdl, xaw, or win32 client type.
• Information about environment which your copy is run in: OS version, window manager, unusual compiler options, localisation, etc.

After submitting the report you should expect further questions. You may be asked for a savegame or backtrace. Therefore you should keep the savegame for some time.

Contents 1 Backtrace 1.1 Getting a core file 1.2 Backtrace on Windows 1.3 Backtrace on failed assertion

Backtrace Edit

A stack backtrace provides very useful information about state of a process. Usually when program crashes, programmers look at the state to investigate a cause of the bug.

To provide a backtrace you can either run the program inside the gdb program or by investigating a core file, which the program may have left on disc after it crashed (see below).

$ gdb freeciv-gtk2
(gdb) run

or

$ gdb freeciv-gtk2 -c core

In first case you have to reproduce a crash, in the second case a state of the program which crashed is already inside the core file. Now you should type

(gdb) bt full

The result will look like this:

#0  0xb78969e7 in raise () from /lib/tls/libc.so.6
#1  0xb789831b in abort () from /lib/tls/libc.so.6
#2  0xb788f885 in __assert_fail () from /lib/tls/libc.so.6
#3  0x08072414 in meswin_thaw () at messagewin_common.c:54
#4  0x0805d31c in reports_thaw () at climisc.c:967
#5  0x0807a718 in handle_thaw_hint () at packhand.c:2701
#6  0x0807aa36 in client_handle_packet (type=PACKET_THAW_HINT,
    packet=0x8bdfb90) at packhand_gen.c:35
#7  0x08059ae8 in handle_packet_input (packet=0x8bdfb90, type=3)
    at civclient.c:390

This is the information we are interested in. If you compile your copy with the '-g' compiler option, the result will contain more useful information.

Getting a core file Edit

On modern Linux, core files are not generated by default when a program crashes, so you may need to run the following command to enable them:

$ ulimit -c unlimited

This should change a crash message like "Segmentation fault" to "Segmentation fault (core dumped)". A file will be created nearby with a name like core or core.12345 which contains debugging information.

It is not generally useful to attach a core file directly to a bug report, as it can't be interpreted without your compiled version of the program; this is why we ask for you to generate the backtrace.

Backtrace on Windows Edit

You need gdb for Windows and the Freeciv binaries with debugging symbols. The necessary files for versions 2.0.9 and 2.1 are available prepackaged from the download server. The zip archives should be extracted into the Freeciv directory and then server and/or client can be loaded into gdb with "gdb civserver.exe" and "gdb civclient.exe".

Backtrace on failed assertion Edit

If you get a message like:

in copy_chars_to_string16() [gui_string.c::196]: assertion 'pString != ((void *)0)' failed

You can start your client or the server with the -F parameter to raise a specific signal on assertion failure. Running with gdb, -F SIGINT (usually 2) is especially useful to interrupt the process you can resume with the continue gdb command.