GNOME Bugzilla – Bug 418199
Gmail / Firefox / SeaMonkey / Epiphany fail to manage windows properly
Last modified: 2013-10-03 00:09:36 UTC
Please describe the problem: All applications cited display the same problem. Untitled windows will be created with a corresponding error "GdkWindow 0x####### unexpectedly destroyed". Subsequent attempts to manipulate the window contents by the application will result in additional Gdk-Warning and Gdk-CRITICAL errors. Steps to reproduce: 1. Place ones system under high CPU and/or network load. 2. Create a new window from ones browser (e.g. Firefox / SeaMonkey / Epiphany). 3. Open ones gmail account (http://www.gmail.com). Actual results: SeaMonkey (or Firefox) log will display: (Gecko:2380): Gdk-WARNING **: GdkWindow 0x2453e96 unexpectedly destroyed (Gecko:2380): Gdk-WARNING **: GdkWindow 0x2453e95 unexpectedly destroyed (Gecko:2380): Gdk-WARNING **: GdkWindow 0x2453e94 unexpectedly destroyed (Gecko:2380): Gdk-WARNING **: GdkWindow 0x2453e93 unexpectedly destroyed (Gecko:2380): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed (Gecko:2380): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed (Gecko:2380): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed (Gecko:2380): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed (Gecko:2380): Gdk-CRITICAL **: gdk_window_resize: assertion `GDK_IS_WINDOW (window)' failed (Gecko:2380): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed (Gecko:2380): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed (Gecko:2380): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed Two "untitled windows" will appear. The two "untitled windows" are specific to using gmail. More common is a single untitled window related to a single "tab" in the browser. Experience has shown that closing the untitled windows (mouse clicking the window "X") will crash the browser. Expected results: The creation and display of a tab (or the gmail "sub-windows") should function normally (no windows should be unexpectedly destroyed, no errors should be logged). Does this happen every time? No. The bug is a *pain* to reproduce which is why it has existed for nearly 3 years (go back through the Firefox & Epiphany bug databases). It seems to be highly dependent on system load and perhaps the thread library one is using. Other information: See bugs: Mozilla bug database: https://bugzilla.mozilla.org/show_bug.cgi?id=263160 Gnome bug database: http://bugzilla.gnome.org/show_bug.cgi?id=352408 The problem appears to start with a DestroyNotify condition in gdkevents-x11.c but it is unclear currently what is causing this.
This bug is semi-reproducible. The key aspect appears to be other process CPU usage. In particular, I am 4 for 4 tests when trying to reproduce the bug *while* compiling Mozilla/firefox from source (which takes more than 30 minutes on my system). The conditions are: 1) The browser (SeaMonkey or Firefox) having been in use for several days (so it has a fragmented heap -- it isn't clear whether this is an essential requirement). 2) Start an CPU intensive set of tasks (e.g. a Mozilla build or builds of many system packages). This is different from running a single CPU bound task, perhaps due to the way the Linux scheduler works. 3) The browser has www.google.com as the default home page. 4) Ctrl-N to bring up a new browser window (opening www.google.com). 5) Type http://www.gmail.com into the URL box and hit return. One gets 4 GdkWindow unexpectedly destroyed errors (consistently) in the browser console window followed by a host of other errors involving failed assertions due to the fact that the browser is trying to manipulate nonexistent or incomplete objects. Closing the parent gmail window (*not* the mis-created secondary windows) will cause the secondary windows and the parent window to close. This process (4-5 above) can be repeated. It is useful to note that during the loading of ones Gmail Inbox, gmail will display "Loading" in the upper left corner of the new window, followed by Loading in a red box in the upper right corner of the window. The popup untitled windows will appear shortly after the red box is displayed. If one doesn't see the Loading messages or sees them only briefly then one probably does not have enough of a load on the CPU and/or network to reproduce this problem. As stated in the other bug reports -- this bug isn't specific to Gmail, Javascript or the specific browser. Gmail does however appear to be particularly effective at reproducing the bug.
Folks, this bug is very real and very painful. I think a more descriptive name for the bug is "firefox frames open in new and disembodied GTK+ windows, leaving firefox unusable" If any GTK+ experts see this, please check the description of the bug (reference in post #1). It contains loads and loads of documentation of the bug. Personally, I can get reproduce the bug by opening a single site, www.marketwatch.com, in a single window of a single browser. Give it a day and will occur. The autoupdate of the Marketwatch site will make it happen. Robert Bradbury has described faster methods for tripping up the bug above. Please help!
I can confirm this bug. It happens with Firefox very often, lately. It seems there's some relation to the age of the Xsession the how often you reboot. It's very painful because I always have to kill the whole Firefox process to make it go away for an hour or two. Please fix it soon! Thanks.
Reading this and the mozilla.org bug, I see no reason to believe this is a gtk bug, in fact it appears that the bug's cause is still pretty much unknown. I am not a gtk developer, but just as friendly advice, I doubt any gtk developers can help with this without either 1) a self-contained compilable test case that is smaller than "all of gecko" or 2) a detailed explanation of what goes wrong, why, and why it's a gtk bug and not a gecko bug. To debug this, someone has to develop a detailed understanding of what's going on. Exactly _what_ goes wrong, _where_, and _why_. What is the sequence of events? If something is NULL that should not be, what was supposed to set it to not-NULL and why didn't it? If a window was unexpectedly destroyed, who called XDestroyWindow() and why did they call it? What kind of window was it that was destroyed (a GDK "foreign window," a normal GdkWindow, ... ?) If there were multiple threads screwing with the window, what was the expected locking (who was supposed to call gdk_threads_enter()/leave()) and what was the actual locking? If you can reproduce the bug when running GTK in "--sync" mode (there is some environment variable equivalent if mozilla doesn't pass that through) then your backtrace from the first warning will reveal the caller of XDestroyWindow. So you might try running with fatal warnings (I think G_DEBUG=fatal_warnings) and with --sync, under gdb. Without --sync, the backtrace from the first warning won't mean much since it will probably just be an async event arriving from the network, and the caller of XDestroyWindow() won't be on the stack. I would guess though that if as described in the mozilla bug, the "unexpected destroy" is a symptom of creating a window without a parent, that this "unexpected destroy" warning is already too late to find the root cause. Instead, you should be figuring out why the parent was NULL. What was supposed to set it to non-NULL? Why didn't it work? The theory on the mozilla bug about an X window not being created yet could only be true if you had multiple threads or processes involved; when creating an X window ID, if you want to pass it to another process, you must XSync() (or I believe there's a GDK equivalent) first. The sync will block until the X server ack's the window creation request, which means the window now exists. The same situation could come up for passing an X window ID between threads *if* one of the threads has its own display connection. However, if all threads are using the GDK display connection and gdk_threads_enter/leave then afaik it is completely impossible to have a problem with not-yet-created windows. All X requests sent through GDK will have to be *after* the window create request in the request queue, so it's guaranteed that said requests will see the created window. I don't think this theory about partially created windows is very plausible, if you know there's a parent that's NULL that should not be, I think the thing to track down is why that thing is NULL. In general, tracking down anything after the *first* problem that occurs is probably a waste of time. The first problem is the cause... so if there's something that shouldn't be NULL and that's the first problem, focus on that.
*** Bug 563592 has been marked as a duplicate of this bug. ***
See also: http://bugzilla.mozilla.org/view_bug.cgi?id=263160 http://bugzilla.mozilla.org/view_bug.cgi?id=461656 http://bugzilla.mozilla.org/view_bug.cgi?id=467744 mentioned in bug 563592 comment #0 (now a dupe of this bug) for more info and "informative stack traces" (especially 467744).
(In reply to comment #6) Oops, wrong URLs. http://bugzilla.mozilla.org/show_bug.cgi?id=263160 http://bugzilla.mozilla.org/show_bug.cgi?id=461656 http://bugzilla.mozilla.org/show_bug.cgi?id=467744
The upstream bug reports have been closed as this no longer seems to be an issue. Doesnt look like the cause was ever discovered. Marking as obsolete.
Bug 581526 was the cause, but Gecko uses fewer windows now and so is not so unlucky.