Comment 59 for bug 226470

Erik, It sounds as if you have the right approach. This entire process is a real *pain* due to the need of getting the .so's right. That is why I attempted a 2.0 compile with as many static debug libs as possible. It appears at this time that given general Linux system configurations and the Firefox dependencies on system libraries that it is impossible to actually compile a fully "static" Firefox under Linux (see bug 372269 for example).

Now, with respect to your debugging scenario. If you have the firefox-bin installed correctly (and all of the libraries upon which it may depend -- dicey question I'll admit). The firefox-bin should start up and run (if it doesn't then there is some kind of library compatibility problem).

So the simple question is can you get firefox-bin up and running on your machine. If it runs, then at least we have the possible library incompatibility problems under control.

Now, firefox-bin is compiled with debugging symbols for Firefox as well as being a static link to the gtk+, glib, stdc++ and glibc with debug symbol libraries. So in theory you should be able to grab almost anything of significance in the binary. Firefox still seems to load "dynamic" libraries, (e.g. thai fonts from either cairo or pango) so it is not fully "stand-alone". The "debugability" of those libraries depends upon how they are compiled on your system (but since that isn't the focus of this bug it may be a no-op).

Once you have firefox-bin up and running normally, you can attach it from gdb. Simply gdb the path to the binary and the process number. You then want to set a breakpoint at g_log_default_handler. This should never be reached in normal operation of the browser. It is triggered on the first "window unexpectedly destroyed" error takes place. The problem is that that error is being reported at a level higher than that which is responsible for the problem (blame the GTK+ library architecture). So once Mozilla/Firefox is in its "handicapped" state, it is necessary to get down into the guts by setting a breakpoint around: gdk/x11/gdkevents-x11.c: 1703 which is where the DestroyNotify call is most likely being generated. Then you have to lean on Mozilla/Firefox in the handicapped state and get stack traces from it in the various DestroyNotify conditions to understand precisely when and why it is destroying windows.

I would fully expect, given my experience, that M/F in this state "works" some of the time that one is going to be dealing with kind of a 50:50 probability of the stack traces being useful. The "gold ring" in this case is having someone say this is a stack trace for a DestroyNotify Event which in turn generated Firefox attempting to mess around with a window which no longer existed.

The fundamental questions may be why was the window "destroyed" and why did M/F not recognize it as such (and one would hope compensate for it).

As a warning, I do not know if you will be able to work with this in your proposed multi-profile scenario. I suspect that one is going to have a problem of attaching multiple gdbs to multiple firefox-bin's and attempting to manage that. That sounds a bit tricky.