Closed Bug 370915 Opened 17 years ago Closed 17 years ago

Firefox popup window bug and GDK/GTK/GLIB errors

Categories

(Core :: Widget: Gtk, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 263160

People

(Reporter: robert.bradbury, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070201 SeaMonkey/1.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2) Gecko/20070214 Firefox/3.0a2

This bug has been reported before, perhaps multiple times.  It has been in Firefox 1.5 and Firefox 2.0.  This is the documentation on producing it in Firefox 3.0a2.

The error typically shows up under very high window/tab usage.  Usually memory is nearly maxed out and the CPU is running 50-70% utilization.  Most of this utilization is being consumed by Firefox and/or X.  The error generally appears when one tries to open a window or tab in Firefox and instead of normal operation a new "untitled window" appears with the contents of the desired page.  Forcing a close of that window (via a window Close operation) will cause all Firefox windows to abort (so it is a "critical" bug).  If the untitled window appears as a result of opening an new tab, selecting the tab will display nothing.  Selecting the tab and closing it from within Firefox will close the tab as well as the untitled window without aborting the Firefox session.  So the problem is ultimately that the contents of a tab window is ending up in a separate untitled window.  The problem can also show up as mysterious "popup windows" (again untitled) appearing.  This generally seems to be associated with pages that have some type of autorefresh running (typically news sites).

When this behavior is taking place with the windows & tabs the Firefox "console" will start to issue a number of GDK/GTK/GLIB errors.  The errors are not restricted to simply opening a new tab.  They can occur when gmail is changing windows or when one closes the tab for an "untitled window".

For example, in gmail, returning from a message to ones Inbox, leads to:
(Gecko:13454): Gdk-WARNING **: GdkWindow 0x3a0f55f unexpectedly destroyed
(Gecko:13454): Gdk-WARNING **: GdkWindow 0x3a0f59b unexpectedly destroyed
(Gecko:13454): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'
(Gecko:13454): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(Gecko:13454): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'
(Gecko:13454): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(Gecko:13454): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'
(Gecko:13454): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(Gecko:13454): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'
(Gecko:13454): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(Gecko:13454): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
(Gecko:13454): Gdk-WARNING **: GdkWindow 0x3a0f59c unexpectedly destroyed
(Gecko:13454): Gdk-WARNING **: GdkWindow 0x3a0f59b unexpectedly destroyed
(Gecko:13454): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'
(Gecko:13454): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
(Gecko:13454): GLib-GObject-WARNING **: invalid unclassed pointer in cast to `GtkWidget'
(Gecko:13454): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed
 

Or closing the tab associated with an "untitled window" leads to:
(Gecko:13454): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed
(Gecko:13454): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed
(Gecko:13454): Gdk-CRITICAL **: _gdk_window_destroy_hierarchy: assertion `window != NULL' failed
(Gecko:13454): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

I believe at this time the primary problem is due to the window "unexpectedly destroyed" problem.  All subsequent errors are most likely due to Firefox failing to handle this situation when it occurs in GDK and passing around NULL window pointers.

It appears this an error due to a "DestroyNotify" condition coming back to gdk_window_destroy_notify() in gtk+-2.8.20/gdk/x11/gdkwindow-x11.c.  I have been unable to trace the actual source for the window destruction.  I suspect it is a very subtle timing issue or thread problem because the situation arises *only* under very heavy load conditions.

Reproducible: Sometimes

Steps to Reproduce:
1. "Happens *every* time" if the Firefox has enough windows and tabs opened.  In this case Firefox had 70 windows and hundreds of tabs opened.
2. It seems to require a very busy CPU.  This can be produced with hundreds of active Firefox tabs or may be possible with fewer tabs if one is running an extensive sequence of system "emerges" (under Gentoo).
3. I can provide the sessionstore.js file for when the problem first started on my machine -- but I suspect it will be of little use on a faster machine.  Current machine is a 2.8 GHz Pentium IV with 1.5 GB of memory.
Firefox is consuming 807 MiB VirMem, 518 MiB ResMem, 19.1 MiB ShrMem, 214 MiB XSrvMem.  CPU is running 60-70% User with 40-60% being consumed by Firefox+X.
Actual Results:  
I can provide the sessionstore.js file but I suspect it will not be that useful on any machines faster than a 2.8GHz Pentium IV.  It is not a URL dependent problem.  Its a "How busy is Firefox+X problem."

Expected Results:  
One should be able to open Firefox Windows and Tabs until one runs out of swap space.  One should presumably max out the CPU before this.  In which case one should see: CPU 100%, DISK I/O 0-100% depending on amount of memory and window sizes, extremely low response time for the currently active window.

Large numbers of Firefox windows/tabs should not cause Firefox to miscreate tabs and issue GDK/GTK/GLIB errors on the console.

Running system emerges that consume lots of CPU time (which behaves differently under Linux than a single CPU bound process because it is constantly restarting short run time gcc's and ld's) should not cause similar problems with miscreating tabs and causing GDK/GTK/GLIB errors on the console.

If under Gnome under X11 in Firefox I have 100 windows and 1000 tabs open and Firefox is the top window in my current workspace and Gmail is open in that window then it should behave the same as if I had only one Firefox Window with 0 tabs and only gmail open.  There should be no CPU penalty or change in performance associated with those many inactive windows.  (One should have the option of "pausing" all javascripts that may be associated with minimized windows).

It should be noted that I normally run Firefox with Noscript blocking javascript for all URLs except a few "known to be safe" sites such as Gmail.  Noscript was however not installed with this particular instance of testing Firefox 3.0a2.

The stack trace(s) for the gmail error are attached below.  More extensive full stack traces (including thread apply all bt) as well as the sessionstore.js file are available on request.

It should be noted that returning Firefox to this problematic state is *difficult*.  It requires at least 15 minutes of CPU time to restore a session like this once it has been terminated.  I will attempt to leave the browser and debugger in this state if someone wishes to contact me (soon) about setting additional breakpoints in the GDK/GTK library to determine what is causing the "DestroyNotify" condition. Reproducing the problem is not a "reliable" operation.  One can open a tab that demonstrates the problem, then close it and reopen it and it will not always show the problem again.  The same is true of repeating a sequence of commands in Gmail.  However, once the browser has reached the state where it has demonstrated the problem once, one can generally demonstrate it again if one opens enough windows/tabs.  Closing a large number of tabs and/or windows will tend to minimize the probability of the problem appearing but does not eliminate it entirely.

---- Stack trace of generating "Window ... unexpectedly destroyed" errors ----

Breakpoint 1, 0xb7911d86 in IA__g_log_default_handler (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    message=0x156463b0 "GdkWindow 0x3a0f59c unexpectedly destroyed", unused_data=0x0) at gmessages.c:860
860     {
(gdb) bt
#0  0xb7911d86 in IA__g_log_default_handler (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    message=0x156463b0 "GdkWindow 0x3a0f59c unexpectedly destroyed", unused_data=0x0) at gmessages.c:860
#1  0xb7911288 in IA__g_logv (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    format=0xb7ae5b50 "GdkWindow %#lx unexpectedly destroyed", args1=0xbfaba94c "\234��\003\f4=\"\001")
    at gmessages.c:474
#2  0xb7911499 in IA__g_log (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    format=0xb7ae5b50 "GdkWindow %#lx unexpectedly destroyed") at gmessages.c:517
#3  0xb7ac3546 in gdk_window_destroy_notify (window=0x223d3408) at gdkwindow-x11.c:1209
#4  0xb7aacfcd in gdk_event_translate (display=0x8af8098, event=0x93a7948, xevent=0xbfabaaac, return_exposes=0)
    at gdkevents-x11.c:1722
#5  0xb7aae0f7 in _gdk_events_queue (display=0x8af8098) at gdkevents-x11.c:2225
#6  0xb7aae45f in gdk_event_dispatch (source=0x8b16b20, callback=0, user_data=0x0) at gdkevents-x11.c:2285
#7  0xb7908ab1 in IA__g_main_context_dispatch (context=0x8b16b68) at gmain.c:2045
#8  0xb790bb26 in g_main_context_iterate (context=0x8b16b68, block=0, dispatch=1, self=0x8e8aea8) at gmain.c:2677
#9  0xb790c0a7 in IA__g_main_context_iteration (context=0x8b16b68, may_block=0) at gmain.c:2736
#10 0x08250f02 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x8ed7fe0, mayWait=0) at nsBaseAppShell.cpp:136
#11 0x08251281 in nsBaseAppShell::OnProcessNextEvent (this=0x8ed7fe0, thr=0x8b22c28, mayWait=1, recursionDepth=0)
    at nsBaseAppShell.cpp:209
#12 0xb7e8bc96 in nsThread::ProcessNextEvent (this=0x8b22c28, mayWait=1, result=0xbfabacd0) at nsThread.cpp:469
#13 0xb7e52d43 in NS_ProcessNextEvent_P (thread=0xb7ac6bab, mayWait=1) at nsThreadUtils.cpp:225
#14 0x08250fde in nsBaseAppShell::Run (this=0x8ed7fe0) at nsBaseAppShell.cpp:153
#15 0x087ea421 in nsAppStartup::Run (this=0x8ed0e98) at nsAppStartup.cpp:171
#16 0x08077428 in XRE_main (argc=2, argv=0xbfabb174, aAppData=0x88c5d40) at nsAppRunner.cpp:2749
#17 0x0807432a in main (argc=7038023, argv=0x5f6b6467) at nsBrowserApp.cpp:61
(gdb) c
Continuing.

Breakpoint 1, 0xb7911d86 in IA__g_log_default_handler (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    message=0x156463b0 "GdkWindow 0x3a0f59b unexpectedly destroyed", unused_data=0x0) at gmessages.c:860
860     {
(gdb) bt
#0  0xb7911d86 in IA__g_log_default_handler (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    message=0x156463b0 "GdkWindow 0x3a0f59b unexpectedly destroyed", unused_data=0x0) at gmessages.c:860
#1  0xb7911288 in IA__g_logv (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    format=0xb7ae5b50 "GdkWindow %#lx unexpectedly destroyed", args1=0xbfaba94c "\233��\003�L!\021\001")
    at gmessages.c:474
#2  0xb7911499 in IA__g_log (log_domain=0xb7ac6bab "Gdk", log_level=G_LOG_LEVEL_WARNING, 
    format=0xb7ae5b50 "GdkWindow %#lx unexpectedly destroyed") at gmessages.c:517
#3  0xb7ac3546 in gdk_window_destroy_notify (window=0x11214cc8) at gdkwindow-x11.c:1209
#4  0xb7aacfcd in gdk_event_translate (display=0x8af8098, event=0x93a7858, xevent=0xbfabaaac, return_exposes=0)
    at gdkevents-x11.c:1722
#5  0xb7aae0f7 in _gdk_events_queue (display=0x8af8098) at gdkevents-x11.c:2225
#6  0xb7aae45f in gdk_event_dispatch (source=0x8b16b20, callback=0, user_data=0x0) at gdkevents-x11.c:2285
#7  0xb7908ab1 in IA__g_main_context_dispatch (context=0x8b16b68) at gmain.c:2045
#8  0xb790bb26 in g_main_context_iterate (context=0x8b16b68, block=0, dispatch=1, self=0x8e8aea8) at gmain.c:2677
#9  0xb790c0a7 in IA__g_main_context_iteration (context=0x8b16b68, may_block=0) at gmain.c:2736
#10 0x08250f02 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x8ed7fe0, mayWait=0) at nsBaseAppShell.cpp:136
#11 0x08251281 in nsBaseAppShell::OnProcessNextEvent (this=0x8ed7fe0, thr=0x8b22c28, mayWait=1, recursionDepth=0)
    at nsBaseAppShell.cpp:209
#12 0xb7e8bc96 in nsThread::ProcessNextEvent (this=0x8b22c28, mayWait=1, result=0xbfabacd0) at nsThread.cpp:469
#13 0xb7e52d43 in NS_ProcessNextEvent_P (thread=0xb7ac6bab, mayWait=1) at nsThreadUtils.cpp:225
#14 0x08250fde in nsBaseAppShell::Run (this=0x8ed7fe0) at nsBaseAppShell.cpp:153
#15 0x087ea421 in nsAppStartup::Run (this=0x8ed0e98) at nsAppStartup.cpp:171
#16 0x08077428 in XRE_main (argc=2, argv=0xbfabb174, aAppData=0x88c5d40) at nsAppRunner.cpp:2749
#17 0x0807432a in main (argc=7038023, argv=0x5f6b6467) at nsBrowserApp.cpp:61
(gdb) c
Continuing.
Component: General → Widget: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Version: unspecified → Trunk
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
I will confirm that this bug appears to be a duplicate of 263160 and move further discussion to that thread.  It should be noted that this bug was produced using Firefox 3.0a2 and the latest GDK/GTK/GLIB libraries so the bug *is* still present in the most up-to-date systems.
URL: many
You need to log in before you can comment on or make changes to this bug.