The other day I built a debuggable Firefox from the source code. The object directory is obj-debug-moz-hunspell within the source directory. Based on good advice written on https://developer.mozilla.org/en/Setting_up_extension_development_enviro... and the instruction to run the debug build written on https://developer.mozilla.org/en/Build_and_Install, I ran 'obj-debug-moz-hunspell/dist/bin/firefox -g -no-remote -P devel'. That landed me on GDB prompt and could run the debuggable Firefox by simply entering 'run' or setting breakpoints. Everything went well and I could inspect the execution trace by entering CTRL+C to bring back the GDB prompt. But, it went wrong today when I invoked the ProfileManager as in 'obj-debug-moz-hunspell/dist/bin/firefox -g -no-remote -ProfileManager'.

Here is the error message:

--DOMWINDOW == 0 (0xb66ad56c) [serial = 1] [outer = (nil)] [url = chrome://mozapps/content/profile/profileSelection.xul]
[New process 21327]
Executing new program: /media/bond/zzz_ff/mozilla/obj-debug-moz-hunspell/dist/bin/firefox-bin
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
[New process 21327]
[Thread debugging using libthread_db enabled]
./run-mozilla.sh: line 235: 21326 Segmentation fault      $debugger "$prog" -x $tmpfile

Googling for 'debug firefox cannot initialize thread debugging library: generic error' landed me on https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/258578. I found a solution from michiel on 2009-08-01:

Rebuilding glibc and gdb fixed it for me. So I think It's caused by updating the kernel without rebuilding glibc/gdb against the new kernel.

Since rebuilding glibc is not simple, I decided to build GDB from the latest stable source code because of the reasons given in http://blog.vinceliu.com/2009/09/how-to-build-debian-package-for-gdb.html:

I'll use GDB as an example of how to build your own package - for a good reason, firstly because the stock version of GDB that is shipped with Ubuntu is terribly broken. Here's what I mean:

	% gdb --args java
	GNU gdb 6.8-debian
	Copyright (C) 2008 Free Software Foundation, Inc.
	License GPLv3+: GNU GPL version 3 or later 
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
	and "show warranty" for details.
	This GDB was configured as "i486-linux-gnu"...
	(no debugging symbols found)
	(gdb) r
	Starting program: /usr/bin/java Test
	(no debugging symbols found)
	(no debugging symbols found)
	(no debugging symbols found)
	(no debugging symbols found)
	[Thread debugging using libthread_db enabled]
	[New process 16487]
	Executing new program: /usr/lib/jvm/java-6-openjdk/jre/bin/java
	warning: Cannot initialize thread debugging library: generic error
	warning: Cannot initialize thread debugging library: generic error
	warning: Cannot initialize thread debugging library: generic error
	warning: Cannot initialize thread debugging library: generic error
	[New process 16487]
	[Thread debugging using libthread_db enabled]
	Segmentation fault
	

The stock build of GDB doesn't handle multi-threaded applications properly, among other minor issue like not setting the path to point to the correct debug library paths, which makes it unusable for serious debugging tasks.

Secondly, GDB 7.0 has reversible debugging, which makes it doubly tempting to roll my own. Finally, GDB has minimal external and library dependencies, which is an easy example to build a package without going into the complexity of having to generate a chrooted environment.

Using the compiled GDB, the error 'warning: Cannot initialize thread debugging library: generic error' no longer occurs. But, the following error remains although GDB doesn't segfault anymore:

process 20140 is executing new program: /media/bond/zzz_ff/mozilla/obj-debug-moz-hunspell/dist/bin/firefox-bin
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0xb7f774ff: Input/output error.

But, when I simply type 'run' upon entering GDB without setting any breakpoint, everything goes well. This good thing doesn't happen with the stock GDB that will segfault although I just simply type 'run'. So, the stock GDB is really broken and only the GDB needs to be rebuilt instead of rebuilding both the GDB and glibc as what michiel suggested.

Since the compiled GDB does not segfault anymore despite the error message 'Cannot insert breakpoint 0. Error accessing memory address 0xb7f774ff: Input/output error' and I could enter 'step' in the GDB prompt following the error message, I guess the error message occured because the thread containing the main() function at which I set a breakpoint has vanished. However, after performing an update on the system (i.e., GNU/Linux Ubuntu Jaunty), the error message no longer occurs. So, I guess the error message was there because of a bug in the libthread of the system C library before the update.

To conclude, when debugging an application with GDB and the GDB issues a warning: Cannot initialize thread debugging library: generic error, building your own version of GDB from the source may solve the problem.