Steps to reproduce:
1. Perform an action in Firefox (or likely Mozilla, Seamonkey or any of the mozilla library based browsers/tools) which deletes a window while the system is somewhat busy.  Most frequently occurs when redrawing windows in Gmail (e.g. after posting an email and returning to ones Inbox, or perhaps returning from a folder to ones Inbox) but can also occur when creating new tabs in a window or deleting a tab.
2. Best if done when the system has a heavy CPU load and/or heavy memory load (causing threads to be suspended and potentially swapped out). 
3. Result in the standard error output is "GdkWindow 0x######## unexpectedly destroyed".  Firefox (browser) performance can vary from a SEGVIO which crashes the program to the creation of an "orphan" window (the closing of which (rather than its parent tab) will crash Firefox.


Stack trace:
The bug has been around for a *long* time.  Please review bugzilla.mozilla.org Bugs #263160, #461656 and especially #467744 which contains some of the more informative stack traces.

The problem is in gdkwindow.c:gdk_window_new() with the call:
  window = _gdk_window_new (parent, attributes, attributes_mask);
and the subsequent use of "window" and "private" which will cause the failure of the statement:
  private->redirect = parent_private->redirect
if "window" and subsequently "private" are NULL.

This can occur if asynchronous threads destroy the "parent" window at some point during the process (see Bug #467744 for additional information).

An obvious fix would be to change "if (parent != NULL) to "if (parent != NULL && window != NULL) or perhaps simply if (private != NULL && parent_private != NULL) before the "redirect" assignment.


Other information:
It would be very helpful if the GDK/GTK developers could review the calls to gtk_window_new() in the Mozilla/Firefox source (there are only a few of them) and any associated calls which destroy windows and could make suggestions to those developers with respect to locking a window being destroyed (to prevent creating children to it) or to lock windows being created (so one cannot destroy the parent until the child creation is complete).  I'm presuming that if one destroys a window in the middle of a hierarchy that a grandparent will inherit the children but don't know enough about how GDK/GTK/GLIB work to be sure.  The important thing is to keep these operations (creation and destruction) atomic so one isn't mucking with data structures which are changing while you work with them.