What's the debug build?

In Firebird download area you can see the debug builds and release builds. Debug builds have files like Firebird-1.5.3.4870-Win32_pdb.exe, while release builds have files like Firebird-1.5.3.4870-0-Win32.exe.

Debug builds are bigger files and contain debug information (function names and similar text). Normally, you should install and run the release build which runs faster and consumes less memory. Debug build should only be used when you have some problems with Firebird (crashes, hanging, etc.) that you cannot diagnose easily (i.e. there is no error message you can use to determine the cause). If your Firebird server crashes, you can run the debug build and attach to it with debugger to trace the error at the point of crash.

Please note that Windows builds are not really debug builds. Those are release builds, with debug info stored in .pdb files.


If you use Firebird on Windows, you can run the 3rd party application called 'Dr.Watson' and run the debug version of Firebird. Make sure that .pdb files are in the same directory as fbserver.exe. Also make sure BugCheckAbort setting in firebird.conf is not commented (remove #) and is set to 1. When Firebird crashes, Dr.Watson will provide you the details about crash that you can send to Firebird developers. Please make sure that you do not use Firebird Guardian, as it acts as debugger and Dr.Watson won't be able to catch the crash. If you wish to debug a running instance of Firebird (because it seems to be stuck), you can do that by invokind Dr.Watson with -p parameter like this: drwtsn32 -p firebird_process_id.


If you use Firebird on Linux, you can use GNU debugger to attach to the running Firebird process by it's process ID (which can be obtained by 'ps ax' command):

# ps ax | grep fb_inet_server
1531 0:00 fb_inet_server # Firebird Database Remote Server
# gdb -p 1531
Attaching to process 1531
Reading symbols from /opt/firebird/bin/fb_inet_server...
(gdb)

Now, do some action that causes it to crash. You'll get the message about it in gdb window. Then type 'bt', which will give you the backtrace - functions that Firebird called internally before the crash. This information can be very helpful to Firebird developers to find the reason for the bug and fix it.

If you use Linux and cannot spend the time to wait for Firebird to crash, you can start it and leave it running. When it crashes, it will dump the core file, which can be later imported into gdb (using -c option). Sending the core file to developers can be more useful as they can produce their own backtraces in that case. You can limit the size of core dump file using the system command 'ulimit' with -c parameter (ulimit command works only for the current login, to make the change permanent consult the manual of your Linux distribution). On some Linux configurations it is set to zero by default, so you'll need to change it first, before you can even get a core dump file.