Comment 90 for bug 226470

I would agree that #349497 and #354970 are the same bug. Bug #366896 might be if one is getting a case where gtk/glib is not catching a case of the window being destroyed and is attempting to manipulate deleted (free-ed) memory structures. Given the number of structure consistency checks in Gtk/Glib is is easy to imagine that they may not have caught them all (I've encountered a few of these even with the most up-to-date libraries). If a user is running on libraries which do not have the debug (& consistency check) options enabled, SEGFAULTs would not be out of the realm of possibility. One needs a stack trace to determine whether the faults are taking place explicitly within Gtk/Glib.

We are clearly in the realm of items being added to various "event" queues for a window while the window is in the process of being destroyed. In cases of high CPU use and/or high memory use -- a window "destroy" operation is not a "guaranteed to go to completion" situation and therefore adding anything to pending event queues (where when they come to the head of a queue they are dealing with a semi- (or completely) destroyed object) is quite problematic.

I maintain my position -- that this is a Firefox (and associated program) problem that one should not be attempting to add activities to a window queue during its destruction. Whether you view this as a Firefox problem or a library problem is open to debate. (For example the most immediate action when one detects a window destroy request is to destroy all Javascripts (and timeouts) or window REFRESH's associated with said window *before* one destroys the window itself!)