Comment 164 for bug 226470
Revision history for this message
|
|
#164 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Maybe, just maybe, I have located at least one source of this problem. People plagued by this over the years may want to look at Bug #467744.
But what I am seeing in that bug is consistent with this bug. It depends entirely on *when* the thread destroying the parent window marks it as "destroyed". The gdk/gtk libraries seem to have this interesting feature that the windows don't immediately disappear when they are "destroyed" but are simply marked as such for a period of time. Of course if one is able to create a new window as a "child" of a window in the process of being destroyed then one is likely to end up with the "orphan" windows we see with this bug.
The asynchronous (multi-threaded) aspect of window creation and destruction is why this bug was/is so sensitive to the machine CPU/memeory (swapping) usage and so difficult to get a handle on.