Jnoyes, not so fast.  Robert O'C. is right -- to solve this bug we are going to have to concentrate experiences and knowledge in one place.  But not solving it is not in the cards now that I have a handle on it (i.e. I've got at least one core complete core dump of the process state when the problem took place as well as at least some understanding of the complexity of the problem.)

Let me recount experiences over the last day.  I backed off on running Firefox with the debug flags enabled (generating the large log files).  I've now recreated the most of the original situation (i.e. all the URLs) + some more.  Am up to 107 windows and 658 tabs in Firefox and it has been running most of the day without any problems.  Its consuming 1.1 GiB VirMem, 1.2GiB Mem, 511 MiB X server Mem (on a 1.5 GiB PhysMem w/ a 1.4 VirMem ulimit set).

I tried to lean on the process switching Firefox+X CPU use theory.  Nada.  I ran glxgears (on a non-DRI X instantiation).  That drove X use up to the point where Firefox was very slow (30+ seconds to minimize a Firefox window).  As Firefox was pretty unusable in that situation I backed off to a situation of running a continual loop of MPlayer video+sound side-by-side with Firefox.  That bumps X usage a bit but does not present the problem with Firefox working after a fashion.  Overall the system is currently @ 100% CPU use, varying something like 30-60% firefox-bin, 10-30% X, and most of the rest gnome-system-monitor.

Now here is the interesting part.  While I was trying to resume the complex Firefox session last night, my seamonkey session went belly-up (with the *same* problem) -- i.e. starts out with "Gecko:Process-#): Gdk-WARNING **: GdkWindow 0x######## unexpectedly destroyed" followed by many errors regarding GDK/GLib trying to manipulate a null objects or assertion failures.

In all cases that I've seen this problem starts out with the "unexpectedly destroyed" WARNING.  So for people who want to work on this you have to start your Firefox/Epiphany/Seamonkey session from a terminal in which you can log the GdK/GLib WARNINGSs/errors.  (And Gtk+(GDK+GTK) & Glib need to be compiled on your system in --enable-debug=yes mode to allow such messages to appear).

Now Firefox 3.0a2 and Seamonkey 1.0.7 are relatively distinct on my system.  The Firefox instantiation is running with the debug libs (separately downloaded and compiled for debugging).  Seamonkey was running with the standard system libraries (though I'm running it with the debug libraries now).  Firefox was compiled in full debug mode, Seamonkey was not.

Now, common aspects.  My normal Firefox runs (including the current run) is running with NoScript enabled (currently not showing the problem when one might expect that it should).  The Firefox 3.0a2 run when the "unexpectedly destroyed" error took place may not have had NoScript in effect.  Seamonkey also does not normally have a NoScript activity in effect.  So this raises the open question of whether Javascripts are running amok in such a way as to corrupt GDK/GLIB memory?  Or perhaps whether a Javascript garbage collection takes place from time to time when CPU resources should be shifting directly between Firefox and X.

To resolve this we are going to need to answer the question of whether the problem ever occurs when Javascript is entirely disabled?

I have yet to see the problem occur when Javascript is completely disabled.  Indeed the probability of the problem taking place seems to correlate with the number of sites allowed to use Javascript.

So it seems to me we are back to
(a) how do we define a case which reliably demonstrates the problem?
(b) does the problem vary with the Javascript usage of "active" URLs?

It is worth noting that the completely asynchronous appearance of the problem is most likely due to sites doing auto-refreshes of some kind.  This problem can occur when the user is doing nothing and the sites are doing something behind the scenes.

Also important to diagnosis...
1) Are you running a hyperthread enabled or multi-core CPU?
2) Are your libraries compiled to provide the GTK debug warnings?
3) What are you running for Linux pthreads? (older glibc or other or newer Posix?)

Eric, I will consider the --class alternative.  I would need to write a perl script to split the sessionstore.js file into a hundred individual firefox invocations (this would take a few days or more given my other priorities).  I agree that the idea has merit but I would like to see how my current state (100+ windows in Firefox + a dozen or in Seamonkey) plays out.

In the mean time I would encourage people interested in this problem to move in the direction of having their gdk+ and glib system libraries compiled with debug symbols available.