gets loaded.) Firefox gets handed a presumed-to-be-complete window descriptor. It then goes off and starts modifying it (presumably trying to make it a <TAB> subwindow of the parent master window). *But* because the CPU is heavily loaded GDK/GLIB<-->X haven't gotten their act together to really have completed creating the window. So Firefox is running along trying to modify a bunch of NULL fields in the window description (leading to all the .... "!= NULL" and (null) errors in the console log file resulting from internal checks in the GDK/GTK/GLIB libraries). The key error seems to be the "GdkWindow ...... unexpectedly destroyed" error which seems to occur at the start of each one of these "untitled window" situations. What if instead the error should be "GdkWindow ...... I haven't finished creating it yet!"? (Perhaps due to delays in getting X to allocate and attach the memory for the window???). It sounds to me like (a) Firefox is missing a window creation method which includes something like: window = gdk_create_window(WAIT_UNTIL_WINDOW_REALLY_EXISTS); or (b) needs some kind of spin wait after requesting the window creation: window = create_window(); wait_until_window_is_completely_valid(window); /* now go attach the window as a tab in the parent window */ It may be that this is a bug in GDK/GTK/GLIB in which case this bug needs to be shifted to those (gnome.org?) developers. Or it may be the case that Firefox is taking an advantage of a library behavior which is "undefined" which happens to work under high CPU load conditions under MS Windows but not under high CPU load conditions under Linux (perhaps because X windows is separate from the O.S. under Linux?) In any case, it *should* be possible for Firefox to work around this problem by determining what fields must be valid in *window before it goes attempting to modify them (and generating all of the NULL/(null) errors). This should be a required Firefox fix for Linux systems because there should be no requirement that people upgrade older system GDK/GTK/GLIB libraries to run Firefox without problems. (You wouldn't require the MS Windows users to upgrade to Vista to run Firefox reliably would you...?) As stated in my previous messages you *can* work around the problem without restarting Firefox if in the parent window you select the (blank) tab associated with the "untitled window" and close it. This will close the tab and close the untitled window. Unless however you close lots of tabs/windows you are unlikely to lower your CPU usage to the point where there is minimal chance of the problem happening again. If Firefox has been running a long time and Firefox (and/or X?) have fragmented heaps the CPU usage will tend to be higher than if you restart them from scratch. (This is a long term problem that should be resolved... but that's another bug.) This entire thread does point out an interesting problem with Firefox stress testing. Either there isn't any or it isn't very robust. As I mentioned in Bug 370915, the problem seemed to happen to me either when Firefox+X were consuming lots of CPU time or when I was executing other high CPU load conditions, e.g. an package emerge of openoffice, seamonkey, etc. -- something that takes hours of CPU time and involves thousands of processes with relatively short execution times (seconds). Stress tests which rely on a single CPU bound process running for hours (while testing Firefox performance) does *not* have the same scheduling characteristics under Linux as many short running processes (something I only found out by reading some of the Linux kernel scheduler documentation). So, perhaps someone could go digging into the Firefox tests and see if there are any many-window/many-tab performance tests and or whether they are good enough to test under (a) High alternate CPU load and (b) High alternate memory load conditions. For example, is there a test which simply calls Firefox with the home page of the largest 500, 1000, 2000 corporations (one could hand them to Firefox as command line arguments). Is there a test that opens up 2000 tabs @ Amazon.com? All of the URLs on the first 20 pages of digg.com? The last 5000 slashdot.org stories? (I can easily write a script that opens OMIM or PubMed URLs (there are hundreds of thousands and millions of those respectively) but the National Library of Medicine has bandwidth constraints on page download frequency). In the meantime if anyone can tell me precisely what source file in the mozilla source tree does the window/tab creation, I may see if I can use that to track down what is causing the "DestroyNotify" error coming out of GTK.

Ok, I, as author of Bug 370915, agree that we are all talking about the same bug and am noving discussion from Bug 370915 to Bug 263160. Wrestling with this is difficult unless you are adept at building Firefox and system libraries completely in debug mode. It took me months to work out how to do this but I now have such a system (a "debug" version of firefox-bin alone without the shared libraries is 130MB). To debug this specific problem easily it appears that you also need to be using gtk+ libraries (gdk & gtk) and the glib libraries (glib) compiled for debugging. Having libstdc++ and glibc compiled for debugging helps as well. (minus points to the Firefox developers for not releasing a static binary for Linux with all of these included!). I am currently *still* running the gdb & firefox instance in the state that produces the bug in the hope that we can figure out what to do with it (I'm filing this bug report using a different seamonkey process set). As stated in the series of bug reports, the bug isn't easy to reproduce -- but once you get Firefox+X into the state where it is consuming a significant fraction of CPU time (40-60% minimum?), and depending on what other processes are consuming CPU time, you can make it happen without too much trouble. I thought memory usage was the problem initially but I now no longer think that is the real problem. The problem is that if you leave Firefox running for days, and/or have opened and closed lots of windows the Firefox heap becomes increasingly fragmented and it take more CPU time to allocate or deallocate anything from the heap. This becomes problematic if one is near the system physical memory limits (active resident memory ~= total physical memory) because running through the fragmented heap may require paging which will of course make the process slower. My current working hypothesis is that there is a subtle coordination/timing problem between Firefox, GDK/GLIB & X. Here is the scenario. My Firefox is currently using 214 MiB of X Server Memory according to the Process Monitor. I believe that X programs map shared memory and then coordinate when Firefox can write into it and when X can read from it. Firefox says "create a new tab". Firefox talks to GDK/GLIB they talk to X and begin this process. (I am relatively well qualified to debug C programs but relatively illiterate about Firefox/GDK/GLIB/X). Firefox says "create a window", GDK/GLIB<-->X then go off to do this. Remember there is no window title at this point (that gets assigned later when the page gets loaded.) Firefox gets handed a presumed-to-be-complete window descriptor. It then goes off and starts modifying it (presumably trying to make it a <TAB> subwindow of the parent master window). *But* because the CPU is heavily loaded GDK/GLIB<-->X haven't gotten their act together to really have completed creating the window. So Firefox is running along trying to modify a bunch of NULL fields in the window description (leading to all the .... "!= NULL" and (null) errors in the console log file resulting from internal checks in the GDK/GTK/GLIB libraries). The key error seems to be the "GdkWindow ...... unexpectedly destroyed" error which seems to occur at the start of each one of these "untitled window" situations. What if instead the error should be "GdkWindow ...... I haven't finished creating it yet!"? (Perhaps due to delays in getting X to allocate and attach the memory for the window???). It sounds to me like (a) Firefox is missing a window creation method which includes something like: window = gdk_create_window(WAIT_UNTIL_WINDOW_REALLY_EXISTS); or (b) needs some kind of spin wait after requesting the window creation: window = create_window(); wait_until_window_is_completely_valid(window); /* now go attach the window as a tab in the parent window */ It may be that this is a bug in GDK/GTK/GLIB in which case this bug needs to be shifted to those (gnome.org?) developers. Or it may be the case that Firefox is taking an advantage of a library behavior which is "undefined" which happens to work under high CPU load conditions under MS Windows but not under high CPU load conditions under Linux (perhaps because X windows is separate from the O.S. under Linux?) In any case, it *should* be possible for Firefox to work around this problem by determining what fields must be valid in *window before it goes attempting to modify them (and generating all of the NULL/(null) errors). This should be a required Firefox fix for Linux systems because there should be no requirement that people upgrade older system GDK/GTK/GLIB libraries to run Firefox without problems. (You wouldn't require the MS Windows users to upgrade to Vista to run Firefox reliably would you...?) As stated in my previous messages you *can* work around the problem without restarting Firefox if in the parent window you select the (blank) tab associated with the "untitled window" and close it. This will close the tab and close the untitled window. Unless however you close lots of tabs/windows you are unlikely to lower your CPU usage to the point where there is minimal chance of the problem happening again. If Firefox has been running a long time and Firefox (and/or X?) have fragmented heaps the CPU usage will tend to be higher than if you restart them from scratch. (This is a long term problem that should be resolved... but that's another bug.) This entire thread does point out an interesting problem with Firefox stress testing. Either there isn't any or it isn't very robust. As I mentioned in Bug 370915, the problem seemed to happen to me either when Firefox+X were consuming lots of CPU time or when I was executing other high CPU load conditions, e.g. an package emerge of openoffice, seamonkey, etc. -- something that takes hours of CPU time and involves thousands of processes with relatively short execution times (seconds). Stress tests which rely on a single CPU bound process running for hours (while testing Firefox performance) does *not* have the same scheduling characteristics under Linux as many short running processes (something I only found out by reading some of the Linux kernel scheduler documentation). So, perhaps someone could go digging into the Firefox tests and see if there are any many-window/many-tab performance tests and or whether they are good enough to test under (a) High alternate CPU load and (b) High alternate memory load conditions. For example, is there a test which simply calls Firefox with the home page of the largest 500, 1000, 2000 corporations (one could hand them to Firefox as command line arguments). Is there a test that opens up 2000 tabs @ Amazon.com? All of the URLs on the first 20 pages of digg.com? The last 5000 slashdot.org stories? (I can easily write a script that opens OMIM or PubMed URLs (there are hundreds of thousands and millions of those respectively) but the National Library of Medicine has bandwidth constraints on page download frequency). In the meantime if anyone can tell me precisely what source file in the mozilla source tree does the window/tab creation, I may see if I can use that to track down what is causing the "DestroyNotify" error coming out of GTK.