368260 - Firefox opens untitled windows and performance is poor

Status: RESOLVED DUPLICATE of bug 263160

(Core :: Widget: Gtk, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en; rv:1.8.0.8) Gecko/20061112 Epiphany/2.16 Firefox/1.5.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.8.0.8) Gecko/20061112 Epiphany/2.16 Firefox/1.5.0.8

If an extended number of Firefox sessions are opened (dozens of windows and hundreds of tabs) Firefox performance will begin to fail due to interactions between Firefox, the X windows system and the Pthreads modules.

It should be emphasized that in this state Firefox is "dysfunctional".

Examples of errors (long):rea


(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec4454 unexpectedly destroyed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_resize: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec4458 unexpectedly destroyed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec4457 unexpectedly destroyed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec4456 unexpectedly destroyed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec4455 unexpectedly destroyed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_resize: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_resize: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: _gdk_window_destroy_hierarchy: assertion `window != NULL' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: _gdk_window_destroy_hierarchy: assertion `window != NULL' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec441f unexpectedly destroyed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec445c unexpectedly destroyed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec4455 unexpectedly destroyed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_user_data: assertion `window != NULL' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_set_back_pixmap: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_resize: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_hide: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-CRITICAL **: gdk_window_show_unraised: assertion `GDK_IS_WINDOW (window)' failed

(Gecko:21590): Gdk-WARNING **: GdkWindow 0xec44c6 unexpectedly destroyed

(Gecko:21590): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'

(Gecko:21590): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed

(Gecko:21590): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'

(Gecko:21590): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed

(Gecko:21590): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWindow'

(Gecko:21590): Gtk-CRITICAL **: gtk_window_move: assertion `GTK_IS_WINDOW (window)' failed

(Gecko:21590): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWindow'

(Gecko:21590): Gtk-CRITICAL **: gtk_window_move: assertion `GTK_IS_WINDOW (window)' failed
--------------------------------------------------------------------------

These errors indicated in the console window of Firefox translate into Firefox spawning "untitled windows" which do not function as normal windows.  Closing an untitled window will cause *all* Firefox windows to abort (bad).  This behavior tends to be tied critically to the behavior of normal windows under Firefox -- Firefox seems to be asserting reconfiguration or recreation of windows which the X Windows manager refuses to accept and Firefox ignores such indications.  This is a concurency and syncronization problem.

Importantly this is using the more recent releases of X11 (x11-7.0) and the recent versions of gcc (4.1.1) and the nptl versions of the thread libraries.

Either (a) Firefox is abusing X windows commands; or (b) there is a bug in the nptl (doubtful); or (c) there is a bug in gcc 4.1.1 (equally doubtful).

The assertion that Firefox is abusing X windows commands is based on the fact that X windows *is* generating error messages that indicate that calls are being made on invalid objects.  This in turn translates into the well known topic that Firefox is extremely lax with regard to catching errors (and responding to them in a reasonable way -- Firefox ignores lower level errors such as memory allocation failures!!!) being propagated up from lower level libraries.  In short Firefox assumes that the lower calls "work" and is not dealing with the cases where they do not. 

With regard to the performance issue.  I fail to understand why a system with a single active window (namely *this* Epiphanay window entering this bug) should have a CPU busy statistic (from gnome process-manarger) for Firefox of 40+%.  After all Firefox is *NOT* an active window.  What can Firefox be doing that requires 40% of the CPU time when it is *not* an active window???  [I have confirmed this -- Firefox on gnome-system-monitor is consuming anywhere from 25-60% of the global system CPU time.  Epiphany is consuming 5-10%.]

Now one could argue that this the excessive CPU consumption is due to Firefox state monitoring, e.g. "save session" capabilities.  But I would argue that CPU consumption of those capacities should revert to zero if the session is unchanging (from a real time perspective).

So here is the fundamental question: Do you perform Firefox reliability tests under Linux in an environment of extreme memory resource and/or CPU stress, i.e. you have to be testing Firefox when memory usage is maximized (so the system is swapping) and there is insufficient CPU avialable (so concurrency issues will raise their ugly heads)?  I would stress that the Firefox 1.5.0.x problems appear to be due to concurrency issues -- and *you* (the Firefox developers) do not get a pass by saying "oh use the most recent release".  Why should I invest *my* time to test a release under high stress conditions that you yourselves have not tested???  [I will note as an aside that it is *IMPOSSIBLE* to compile a Firefox release with complete debugging capabilities.  There is such a reliance on loaded libraries that compiling a completely "debugable" (e.g. static) binary with full symbol libraries is virtually impossible (I *have* tried to do this -- and though mind you I haven't given up on it yet -- it is  *very* difficult and *not* something your developers have enabled).]

If you do not have a single static executable module with all debugable symbols that can be loaded into memory and executed under all conditions -- you do not have a true "package" that you can reasonably expect people to file bug reports on.  You are asking people to file bug report on something which cannot probably ever be replicated -- so it is pointless to file bug reports.  I have *had* Firefox hang in the execution of the upgrades of the flashplayer module -- which of course has no symbols and it seems to hang in the threads library -- 

So *all* Firefox development paths (at least under Linux) are flawed.  You cannot distribute a completely static Firefox with completely resolvable symbols
that depends *only* on the binary system call interface on a Linux system!

The net conclusion that I would draw from that is that it is impossible to debug Firefox on Linux systems.  *You* have no way to draw a hard line at the system call interface level.  You are dependent on the system library level which may well vary from system to system (I can compile system libraries under Gentoo with or without NPTL) which will of course change concurrency issues.  So you have no way of determining which problems will occur if I have or do not have NPTL.

Yet another example of Firefox developers saying "Only Windows is important" -- "screw the open source operating systems".

If you want to correct this misperception on my part, you should produce a page which says explicitly *what* the Q&A testing for Firefox is under various versions of Linux with various system subcomponents.


Reproducible: Always

Steps to Reproduce:
1. Open a large number of tabs/windows.
2. Generate another external application under Linux consuming a significant fraction of CPU time.  Under Gentoo this is common when one is "emerging" packages even when the package emerges are niced -17.  The delay in responsiveness in CPU time is critical to demonstrating poor performance in the pthreads library and/or the Firefox Windows (which actually perform dysfunctionally).
3. Open up a large number of Firefox windows to a variety of web sites.  Firefox and X will flip-flop back and forth between consuming most (>50%) of the available CPU time *even* though a single window in Epiphany is the active window (that which I am typing this message in).

If the window is minimized its CPU consumption should be equally minimal.
If the window is "on top" on the current desktop then the downloads its tabs are requesting should receive top priority.  The window on the top of the desktop should be receiving all of the CPU, memory and network priority.  If you cannot implement that then you should be documenting bugs in the O.S.
Actual Results:  
Firefox is:
a) Extremely slow in starting up when a large number of pages are involved.
   (15min or more is not unusual).
b) Firefox can be extremely slow in a "mandated" shutdown -- if the paging requirements of the heap memory require the paging in of unavailable pages.
c) Firefox currently, to the best of my knowledge, has no way to schedule "pages in front of ones face" vs. "minimized pages".

It is not unusual for me to work with dozens or hundreds of pages.  At the point that Firefox becomes unresponsive I switch to different browsers.  I have resorted to the effort of programming utilities that will translate between browser state sessions between Epiphany, Firefox and Opera to allow me to optimize browsing bandwidths.  So when Firefox performance "sucks" I'll switch to Epiphany or Opera or ... so I get the performance that I know the system can provide.  This isn't rocket science...  The system is over a DSL line, has 1.5 GB of memory, is using a Pentium 4, if I request a page the page should download and display *extremely promptly.  When it doesn't it is a *software* problem.  If you can't get decent performance out of Firefox on Linux systems you should be driving changes to the Linux system.  Last time I checked Linux systems were being released on a monthly basis -- vs. Microsoft (:-( **** from hell) that were being released on a semi-yearly (or more) basis).

Expected Results:  
You should be able to load up hundreds of windows and hundreds of tabs and still expect *response* from the window in front of ones face.

It is the window in front of ones face that counts.  And I can "switch" windows to the title of any other window -- at which point the priority (of download and display) should switch as well.

When you *really* get a Linux perspective, contact me.  I have spent months of my life (thousands of $) trying to compile a static Firefox (it is *not* something that happens "out-of-the-box" in your releases).  I have bought new hardware (a 320MB disk drive) so I might potentially keep up to your "current release" (because compiling a fully static Firefox and/or a Firefox with libraries with full debugging symbols is *not* a small task and requires large amounts of disk space).  Since you seem to disdain any bug reports not filed using the "most current release", particularly those not related to that closed source, monopolistic, operating system otherwise known as "windows", I am hardly optimistic.

A *true* programmer would want to know *why* does Firefox 1.5.0.8 fail under Linux in interfacing to X11 7.0 and the gcc 4.1.1 releases of NPTL.  But do I expect that to be investigated?  Probably not.

When you release a fully static Firefox with full debugging symbols under Linux, *then* and only then will I begin to believe you are serious about improving your "product".

Comment 1

[James McMechan]

I just had this happen today 2007-12-02, I had about 10 windows open, some with 30  most with 6-10 tabs open when firefox crashed, this time it took my session history with it so I went searching for the bug.
I am running with Firefox 2.0.0.9 so it does not appear to be fixed yet.
I had seen the Gdk- errors but am not up on gdk
This happened on a hp 6105us laptop with 2G RAM 2G swap nvidia Geforce 6150 Go video AMD64 MK-36 running 64 bit gentoo.
untitled windows would pop up and if one is closed firefox crashes.
The untitled windows had no scroll bars or buttons and would not page down.