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.


Do you find this FAQ incorrect or incomplete? Please e-mail us what needs to be changed. To ensure quality, each change is checked by our editors (and often tested on live Firebird databases), before it enters the main FAQ database. If you desire so, the changes will be credited to your name. To learn more, visit our add content page.

If you are a commercial tool maker and your tool features a great way to handle the issue written about in this FAQ, please check out our advertisement page.



All contents are copyright © 2007-2017 FirebirdFAQ.org unless otherwise stated in the text.


Links   Firebird   News   FlameRobin   Home Inventory powered by FB  
Add content   Advertise   About  

Categories
 Newbies
 SQL
 Installation and setup
 Backup and restore
 Performance
 Security
 Connectivity and API
 HOWTOs
 Errors and error codes
 Miscellaneous