Bug #226470 “untitled popup window” : Bugs : firefox-3.0 package : Ubuntu

Revision history for this message

In Mozilla Bugzilla #263160, Slicedlime (slicedlime) wrote on 2004-10-07:

#1

Managed to grab a couple of screenshots. Note the ad banner image (which is an
iframe) that has turned up in the wrong place, its own window. Also, the
blue-ish box in the middle of the page is my desktop background image hanging
around from a workspace change:
http://www.mozilla.se/bugs/firefox-bug-1.png

Right after that, reloading the page made it even worse. Now both the iframe of
the banner and the frame of the whole tab got ripped out. Note how the window
covers the toolbar of the "real" firefox window, and the "Screen Shot" window
showing through the firefox window is actually the first screenshot, which again
is on a different workspace. That area isnt updated at all - dragging a window
across it creates a "trail".
http://www.mozilla.se/bugs/firefox-bug-2.png

Revision history for this message

In Mozilla Bugzilla #263160, Nilbus (nilbus) wrote on 2005-03-18:

#2

I've experienced this bug several times as well. It happens after I've had
firefox open for several weeks. On each page reload, on the frames page, any of
the frames may "jump out" of the page in a new window. Between 80 and 90% of
the time, the frame will actually fix itself on reload, but may pop out on
subsequent reloads.

Restarting firefox does fix the problem. Everything Mikael said was true for me
as well.

I run Gentoo Linux with Xorg and Blackbox WM.
I took a screenshot: <a
href="http://www.nilbus.com/pub/firefox-frames-bug.png">http://www.nilbus.com/pub/firefox-frames-bug.png</a>

Revision history for this message

In Mozilla Bugzilla #263160, Trevor-watson (trevor-watson) wrote on 2005-04-06:

#3

I have this happen at least once a day on FF 1.0.2 on Solaris, running under
GNOME. It has been happening since FF 0.9 and on more than one GNOME release.

Revision history for this message

In Mozilla Bugzilla #263160, Gervase Markham (gerv-mozilla) wrote on 2005-09-27:

#4

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/

Revision history for this message

In Mozilla Bugzilla #263160, Gervase Markham (gerv-mozilla) wrote on 2005-10-13:

#5

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Revision history for this message

In Mozilla Bugzilla #263160, Philringnalda (philringnalda) wrote on 2006-09-26:

#6

Reopening, since I have a couple more to mark as duplicates...

Revision history for this message

In Mozilla Bugzilla #263160, Philringnalda (philringnalda) wrote on 2006-09-26:

#7

*** Bug 348734 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Philringnalda (philringnalda) wrote on 2006-09-26:

#8

*** Bug 354104 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Bugzilla-hernmarck (bugzilla-hernmarck) wrote on 2006-10-04:

#9

Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

I can confirm this bug - I often leave ff (and Mozilla-suite) open for days/weeks. Early 2006 I started "facing" this bug and hating it :-)
I often work with Typo3, phpMyAdmin and other tools heavily using frames.
This summer I also noticed this bug in mozilla
Mozilla/5.0 (X11; U; Linux x86_64; de-AT; rv:1.7.13) Gecko/20060411
There I have about 30 tabs open - all the time (news sites etc).

I never saw it on MS Windows, I mostly work on linux (SuSE 10.0 - Xorg 6.8.2, kde). Until end of 2005 I had SuSE 9.1 (XFree 4.3.99, kde) and can't remember this behaviour.
So I think it's also depending on the Window-Manager...

I always try to continue working without closing firefox. When closing the tab with the frames the frame-windows are also disappearing. But sometimes it's useless to try opening the same framepage in another tab or ff window - you always get the "flying frame windows". Just now: after waiting (and reporting here) I can open the last problem frame page again without problems, so maybe it's also a time problem...???

Reproducable: no step-by-step.
It happens when it happens (having ff open for some days and using many frame websites).

/Christian

Revision history for this message

In Mozilla Bugzilla #263160, Robert-leathley (robert-leathley) wrote on 2006-10-04:

#10

For me (see Bug 354104) it happens on SLES9, XFree86 4.3.99, Window Maker 0.92.0

Revision history for this message

In Mozilla Bugzilla #263160, Amettler (amettler) wrote on 2006-10-26:

#11

Created an attachment (id=243592)
gtk errors logged to stderr when bug occurs

Revision history for this message

In Mozilla Bugzilla #263160, Amettler (amettler) wrote on 2006-10-26:

#12

I can confirm occurence of this bug with Debian, KDE, on i386 and amd64; I usually keep firefox open for weeks.
At the moment, this and bug 341731 are more or less the only stability issues I'm experiencing. One can interact with the dislocated content as usual, but closing them or clicking in the pane where they should be rendered causes a crash; reloading the page several times will eventually result in the frames being rendered correctly, but loading another page will often cause the dislocation to occur again. "tail -n 1000 .xsession-errors | grep Gecko" is attached.

Revision history for this message

In Mozilla Bugzilla #263160, Dev-null-gmx (dev-null-gmx) wrote on 2006-12-05:

#13

I can confirm this bug. It happens very often on my Debian Computer too. It seems to be connected to the time the xsession (and/or the computer) is running. Furthermore I've noticed this bug the first time after upgrading to a dual-core system using smp.

Why is the status still unconfirmed after several people have confirmed this bug?

Revision history for this message

In Mozilla Bugzilla #263160, Philringnalda (philringnalda) wrote on 2006-12-05:

#14

It's unconfirmed partly because it's certainly in the wrong product and component, though the right one isn't clear, and partly because nobody knows what's at fault, and mostly because it doesn't make any difference: if someone chooses to work on it, the difference between this report being UNCO and NEW won't matter to them, while there's a slight chance that someone looking through UNCO bugs will say "oh, I know something that causes that..."

Revision history for this message

In Mozilla Bugzilla #263160, Dev-null-gmx (dev-null-gmx) wrote on 2006-12-06:

#15

Sorry, but I can't follow that argumentation. I'd think the contrary is the case. If there is a confirmed (and very nasty) bug reported by several people, I would assume somebody feels the obligation to correct this bug before the next Firefox release. I mean somebody has to be reponsible for the quality of Firefox. If the bug is unconfirmed, developers might not care about it because to them, it's very possbile that the bug is a problem somewhere else and not in their product.

You're right that if someone chooses to work on it, the difference between this report being UNCO or NEW won't matter to them. Though, I think marking this bug as new will improve the chances that somebody chooses to work on it.

As I can see, the bug was opened in 2004. How many Firefox release have there been since the first report? Why does nobody fix the bugs for new release? (Or at least stop the new releases until somebody is willing to fix the bug.) How can you release new Firefox versions with open bugs? Or do the developers think there are no bugs because even after several confirmations you leave the bug unconfirmed?

I suggest increasing the severity to at least critical because for users who happen to stumble upon this bug, it's very painful.

Revision history for this message

In Mozilla Bugzilla #263160, Braden (braden) wrote on 2006-12-17:

#16

I'm experiencing this in Epiphany; see <http://bugzilla.gnome.org/show_bug.cgi?id=352408>.

Revision history for this message

In Mozilla Bugzilla #263160, Aaron-lithic (aaron-lithic) wrote on 2007-01-17:

#17

*** Bug 367211 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Aaron-lithic (aaron-lithic) wrote on 2007-01-17:

#18

this bug is seriously awful, i also am at a loss why it hasn't been prioritized upwards.

Revision history for this message

In Mozilla Bugzilla #263160, Roc-ocallahan (roc-ocallahan) wrote on 2007-01-17:

#19

It is awful. It's very hard to debug because it's very hard to reproduce. If you can figure out a reliable way to reproduce it, that would help very very much.

Revision history for this message

In Mozilla Bugzilla #263160, Braden (braden) wrote on 2007-01-17:

#20

If my experience is any indication, Epiphany might be a better context in which to reproduce this than Firefox. This bug bites me *frequently* in Epiphany. While I don't have a magic formula for reliably reproducing it, it tends happen within an hour or so of use. "Busy" pages with a lot of IFRAMEs seem especially likely to trigger it. A heavily customized Google home page is one such animal; cnn.com seems to be another.

While Epiphany is my preferred browser, I've tried reproducing this in Firefox--and I haven't had any luck so far.

Oh, and when I do close one of these rogue windows causing the browser to "crash", I don't get a stack. I get a program exit with a return code of 1.

And FWIW, I'm on x86_64.

I'd be happy to help someone familiar with the Mozilla code to chase this down; but without a stack, I'm not sure where to start.

Revision history for this message

In Mozilla Bugzilla #263160, Roc-ocallahan (roc-ocallahan) wrote on 2007-01-17:

#21

My guess is that what happens is a subframe's window gets created as a top level widget by mistake. (The crash occurs later so a stack might not help.) I really have no idea how that could happen. A mess of logging code in nsWindow::NativeCreate might help; maybe run under gdb for a while and use a breakpoint with commands to dump a detailed stack every time a top-level GTK window is created ?

Revision history for this message

In Mozilla Bugzilla #263160, Braden (braden) wrote on 2007-01-17:

#22

I'll give it a shot.

Revision history for this message

In Mozilla Bugzilla #263160, Braden (braden) wrote on 2007-02-02:

#23

Created an attachment (id=253838)
Backtrace from the creation of a rogue window in Epiphany

This is a backtrace from the creation of one of these rogue top-level windows when using Epiphany.

Revision history for this message

In Mozilla Bugzilla #263160, Roc-ocallahan (roc-ocallahan) wrote on 2007-02-04:

#24

In that call to NativeCreate, aNativeParent is non-null. So we should be hitting either
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#2722
or
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#2724
and setting parentGdkWindow or parentGtkContainer to something, which should ensure that this window gets created inside some other window. Can you figure out why it isn't?

Revision history for this message

In Mozilla Bugzilla #263160, Philringnalda (philringnalda) wrote on 2007-02-17:

#25

*** Bug 370787 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Erikred (erikred) wrote on 2007-02-17:

#26

Glad to get my bug report 370787 classified as a duplicate of this one. What Mikael Hedberg and the rest of you have described is exactly what is happening to me.

I think the key to reproducing the bug is to open LOTS of windows with LOTS of tabs in them, say 10-20 windows and a 100 tabs. The more the merrier. And try some of the more prone web sites such as www.marketwatch.com or www.huffingtonpost.com.

I have a hunch that web pages with lots of subframes or flash frames also may provoke the bug faster.

This is really a major annoyance, and seeing how many other people have the problem I vote for upgrading it to critical.

Revision history for this message

In Mozilla Bugzilla #263160, Philringnalda (philringnalda) wrote on 2007-02-19:

#27

*** Bug 370915 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Erikred (erikred) wrote on 2007-02-19:

#28

Bug 370915 is another excellent description of the same problem.

I have some observations to add: In my experience, it is not strictly required
to run out of memory and start chewing up swap space before the problem occurs.
For example, at the moment of this writing I have 3G ram, 1.4G used, 0G swap
used and I already have two disembodied Untitled windows popping up.

I can also confirm the console error messages syndrome, although I had not made
the connection with the disembodied window problem before.

I can however confirm that the cobination of X and my 2-3 firefox processes are chewing up quite a lot of cpu while this is going on.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2007-02-20:

#29

Download full text (7.1 KiB)

Ok, I, as author of Bug 370915, agree that we are all talking about the same bug and am noving discussion from Bug 370915 to Bug 263160. Wrestling with this is difficult unless you are adept at building Firefox and system libraries completely in debug mode. It took me months to work out how to do this but I now have such a system (a "debug" version of firefox-bin alone without the shared libraries is 130MB). To debug this specific problem easily it appears that you also need to be using gtk+ libraries (gdk & gtk) and the glib libraries (glib) compiled for debugging. Having libstdc++ and glibc compiled for debugging helps as well. (minus points to the Firefox developers for not releasing a static binary for Linux with all of these included!).

I am currently *still* running the gdb & firefox instance in the state that produces the bug in the hope that we can figure out what to do with it (I'm filing this bug report using a different seamonkey process set). As stated in the series of bug reports, the bug isn't easy to reproduce -- but once you get Firefox+X into the state where it is consuming a significant fraction of CPU time (40-60% minimum?), and depending on what other processes are consuming CPU time, you can make it happen without too much trouble.

I thought memory usage was the problem initially but I now no longer think that is the real problem. The problem is that if you leave Firefox running for days, and/or have opened and closed lots of windows the Firefox heap becomes increasingly fragmented and it take more CPU time to allocate or deallocate anything from the heap. This becomes problematic if one is near the system physical memory limits (active resident memory ~= total physical memory) because running through the fragmented heap may require paging which will of course make the process slower.

My current working hypothesis is that there is a subtle coordination/timing problem between Firefox, GDK/GLIB & X.

Here is the scenario. My Firefox is currently using 214 MiB of X Server Memory according to the Process Monitor. I believe that X programs map shared memory and then coordinate when Firefox can write into it and when X can read from it. Firefox says "create a new tab". Firefox talks to GDK/GLIB they talk to X and begin this process. (I am relatively well qualified to debug C programs but relatively illiterate about Firefox/GDK/GLIB/X). Firefox says "create a window", GDK/GLIB<-->X then go off to do this. Remember there is no window title at this point (that gets assigned later when the page <TITLE> gets loaded.) Firefox gets handed a presumed-to-be-complete window descriptor. It then goes off and starts modifying it (presumably trying to make it a <TAB> subwindow of the parent master window). *But* because the CPU is heavily loaded GDK/GLIB<-->X haven't gotten their act together to really have completed creating the window. So Firefox is running along trying to modify a bunch of NULL fields in the window description (leading to all the .... "!= NULL" and (null) errors in the console log file resulting from internal checks in the GDK/GTK/GLIB libraries).

The key error seems to be the "GdkWindow ...... unexpe...

Ok, I, as author of Bug 370915, agree that we are all talking about the same bug and am noving discussion from Bug 370915 to Bug 263160.  Wrestling with this is difficult unless you are adept at building Firefox and system libraries completely in debug mode.  It took me months to work out how to do this but I now have such a system (a "debug" version of firefox-bin alone without the shared libraries is 130MB).  To debug this specific problem easily it appears that you also need to be using gtk+ libraries (gdk & gtk) and the glib libraries (glib) compiled for debugging.  Having libstdc++ and glibc compiled for debugging helps as well.  (minus points to the Firefox developers for not releasing a static binary for Linux with all of these included!).

I am currently *still* running the gdb & firefox instance in the state that produces the bug in the hope that we can figure out what to do with it (I'm filing this bug report using a different seamonkey process set).  As stated in the series of bug reports, the bug isn't easy to reproduce -- but once you get Firefox+X into the state where it is consuming a significant fraction of CPU time (40-60% minimum?), and depending on what other processes are consuming CPU time, you can make it happen without too much trouble.

I thought memory usage was the problem initially but I now no longer think that is the real problem.  The problem is that if you leave Firefox running for days, and/or have opened and closed lots of windows the Firefox heap becomes increasingly fragmented and it take more CPU time to allocate or deallocate anything from the heap.  This becomes problematic if one is near the system physical memory limits (active resident memory ~= total physical memory) because running through the fragmented heap may require paging which will of course make the process slower.

My current working hypothesis is that there is a subtle coordination/timing problem between Firefox, GDK/GLIB & X.

Here is the scenario. My Firefox is currently using 214 MiB of X Server Memory according to the Process Monitor.  I believe that X programs map shared memory and then coordinate when Firefox can write into it and when X can read from it.  Firefox says "create a new tab".  Firefox talks to GDK/GLIB they talk to X and begin this process. (I am relatively well qualified to debug C programs but relatively illiterate about Firefox/GDK/GLIB/X).  Firefox says "create a window", GDK/GLIB<-->X then go off to do this.  Remember there is no window title at this point (that gets assigned later when the page <TITLE> gets loaded.)  Firefox gets handed a presumed-to-be-complete window descriptor.  It then goes off and starts modifying it (presumably trying to make it a <TAB> subwindow of the parent master window).  *But* because the CPU is heavily loaded GDK/GLIB<-->X haven't gotten their act together to really have completed creating the window.  So Firefox is running along trying to modify a bunch of NULL fields in the window description (leading to all the .... "!= NULL" and (null) errors in the console log file resulting from internal checks in the GDK/GTK/GLIB libraries).

The key error seems to be the "GdkWindow ...... unexpectedly destroyed" error which seems to occur at the start of each one of these "untitled window" situations.  What if instead the error should be "GdkWindow ...... I haven't finished creating it yet!"?  (Perhaps due to delays in getting X to allocate and attach the memory for the window???).

It sounds to me like (a) Firefox is missing a window creation method which includes something like:
   window = gdk_create_window(WAIT_UNTIL_WINDOW_REALLY_EXISTS);
or (b) needs some kind of spin wait after requesting the window creation:
   window = create_window();
   wait_until_window_is_completely_valid(window);
   /* now go attach the window as a tab in the parent window */

It may be that this is a bug in GDK/GTK/GLIB in which case this bug needs to be shifted to those (gnome.org?) developers.  Or it may be the case that Firefox is taking an advantage of a library behavior which is "undefined" which happens to work under high CPU load conditions under MS Windows but not under high CPU load conditions under Linux (perhaps because X windows is separate from the O.S. under Linux?)

In any case, it *should* be possible for Firefox to work around this problem by determining what fields must be valid in *window before it goes attempting to modify them (and generating all of the NULL/(null) errors).  This should be a required Firefox fix for Linux systems because there should be no requirement that people upgrade older system GDK/GTK/GLIB libraries to run Firefox without problems.  (You wouldn't require the MS Windows users to upgrade to Vista to run Firefox reliably would you...?)

As stated in my previous messages you *can* work around the problem without restarting Firefox if in the parent window you select the (blank) tab associated with the "untitled window" and close it.  This will close the tab and close the untitled window.  Unless however you close lots of tabs/windows you are unlikely to lower your CPU usage to the point where there is minimal chance of the problem happening again.  If Firefox has been running a long time and Firefox (and/or X?) have fragmented heaps the CPU usage will tend to be higher than if you restart them from scratch.  (This is a long term problem that should be resolved... but that's another bug.)

This entire thread does point out an interesting problem with Firefox stress testing.  Either there isn't any or it isn't very robust.  As I mentioned in Bug  370915, the problem seemed to happen to me either when Firefox+X were consuming lots of CPU time or when I was executing other high CPU load conditions, e.g. an package emerge of openoffice, seamonkey, etc. -- something that takes hours of CPU time and involves thousands of processes with relatively short execution times (seconds).  Stress tests which rely on a single CPU bound process running for hours (while testing Firefox performance) does *not* have the same scheduling characteristics under Linux as many short running processes (something I only found out by reading some of the Linux kernel scheduler documentation).

So, perhaps someone could go digging into the Firefox tests and see if there are any many-window/many-tab performance tests and or whether they are good enough to test under (a) High alternate CPU load and (b) High alternate memory load conditions.  For example, is there a test which simply calls Firefox with the home page of the largest 500, 1000, 2000 corporations (one could hand them to Firefox as command line arguments).  Is there a test that opens up 2000 tabs @ Amazon.com?  All of the URLs on the first 20 pages of digg.com?  The last 5000 slashdot.org stories?  (I can easily write a script that opens OMIM or PubMed URLs (there are hundreds of thousands and millions of those respectively) but the National Library of Medicine has bandwidth constraints on page download frequency).

In the meantime if anyone can tell me precisely what source file in the mozilla source tree does the window/tab creation, I may see if I can use that to track down what is causing the "DestroyNotify" error coming out of GTK.

Revision history for this message

In Mozilla Bugzilla #263160, Erikred (erikred) wrote on 2007-02-20:

#30

Robert Bradbury,

I think you are an absolute hero for getting this close to identifying the bug. Operations on a window that X has not yet finished creating seems like a good theory. Please keep up the good work!!

While we are on the topic, is it not strange that X and/or Firefox does not seem to have robust heap management and garbage collection? I mean, If I create huge amounts of tabs, X/Firefox will get very large, but they do not seem to shrink much if I delete the window. Maybe I'm wrong, I'm certainly no expert on the innards of X nor Firefox.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2007-02-20:

#31

Update. I strongly suspect the top level problem area is in:
mozilla/widget/src/gtk2/nsWindow.cpp - nsWindow::NativeCreate(...)
between lines ~2825 tto 2897. The lower level calls include such functions
as:
gtk_window_new(), gtk_window_group_add_window(), gtk_container_add(),
gtk_widget_realize() and gtk_window_set_focus(). The problem is that
...realize() and ...set_focus() functions are called from other than
NativeCreate() so debugging it is tricky.

In the course of trying to debug across a Create-TAB request, gdb ended up
handing me a "Cannot get thread event message: debugger service failed" error.
Attempts to continue Firefox ended up with a SETFAULT and core dump (so I've
lost the error state, though I have the sessionstore.js file for it).

There is some interaction between the Create-TAB request and creating new
threads so the pthread() library gets dragged into this discussion (along with
GDK/GTK/GLIB). I think it would help if people also made clear:
1) What processor you are using.
2) What thread library you are using.

I'm running a Pentium IV (Prescott) which has only 1 core but does support
hyperthreading. I'm using the most recent release of the Linux Posix pthread
library (glibc 2.5 I think) and it looks like GLIB is supposed to be using
pthread_mutex_lock() and pthread_mutex_unlock to get and release locks.

It appears that it may be impossible using gdb (at least on my system) to debug
pthread_mutex functions (setting breakpoints at them results in the "... thread
event..." message mentioned previously).

It may be necessary to compile GLIB with G_DEBUG_LOCKS (glib/gthreads.h) and
set the proper debug flags and/or compile mozilla with MOZ_LOGGING at least for
the widget/src/gtk2 functions (see #define LOG() in
widget/src/gtk2/nsCommonWidget.h. Of course adding logging to either the
widget functions or GLIB may disrupt the timing sufficiently to make the
problem go away. One thing that appears key is the need to find out where the
DestroyNotify is coming from (see
gtk+/gdk/x11/gdkevents-x11.c:gdk_event_translate() -- case DestroyNotify:).
If your Gtk/Gdk library is compiled with debugging, running Firefox with
"export GDK_DEBUG=events" may help provide destroy notify messages on the
console log, but what one really wants is a way to do "_gdk_debug_flags |=
GDK_DEBUG_EVENTS;" (see GDK_NOTE macro in gdk/gdkinternals.h) after you have
loaded up all of the windows & tabs that lead up to the problem state.

I hope the above helps to put our hands around the problem.

Update.  I strongly suspect the top level problem area is in:
  mozilla/widget/src/gtk2/nsWindow.cpp - nsWindow::NativeCreate(...)
between lines ~2825 tto 2897.  The lower level calls include such functions
as:
gtk_window_new(), gtk_window_group_add_window(), gtk_container_add(),
gtk_widget_realize() and gtk_window_set_focus().  The problem is that
...realize() and ...set_focus() functions are called from other than
NativeCreate() so debugging it is tricky.

In the course of trying to debug across a Create-TAB request, gdb ended up
handing me a "Cannot get thread event message: debugger service failed" error. 
Attempts to continue Firefox ended up with a SETFAULT and core dump (so I've
lost the error state, though I have the sessionstore.js file for it).

There is some interaction between the Create-TAB request and creating new
threads so the pthread() library gets dragged into this discussion (along with
GDK/GTK/GLIB).  I think it would help if people also made clear:
1) What processor you are using.
2) What thread library you are using.

I'm running a Pentium IV (Prescott) which has only 1 core but does support
hyperthreading.  I'm using the most recent release of the Linux Posix pthread
library (glibc 2.5 I think) and it looks like GLIB is supposed to be using
pthread_mutex_lock() and pthread_mutex_unlock to get and release locks.

It appears that it may be impossible using gdb (at least on my system) to debug
pthread_mutex functions (setting breakpoints at them results in the "... thread
event..." message mentioned previously).

It may be necessary to compile GLIB with G_DEBUG_LOCKS (glib/gthreads.h) and
set the proper debug flags and/or compile mozilla with MOZ_LOGGING at least for
the widget/src/gtk2 functions (see #define LOG() in
widget/src/gtk2/nsCommonWidget.h.  Of course adding logging to either the
widget functions or GLIB may disrupt the timing sufficiently to make the
problem go away.  One thing that appears key is the need to find out where the
DestroyNotify is coming from (see
gtk+/gdk/x11/gdkevents-x11.c:gdk_event_translate() -- case DestroyNotify:).
If your Gtk/Gdk library is compiled with debugging, running Firefox with
"export GDK_DEBUG=events" may help provide destroy notify messages on the
console log, but what one really wants is a way to do "_gdk_debug_flags |=
GDK_DEBUG_EVENTS;" (see GDK_NOTE macro in gdk/gdkinternals.h) after you have
loaded up all of the windows & tabs that lead up to the problem state.

I hope the above helps to put our hands around the problem.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2007-02-20:

#32

(In reply to comment #31)
> Update. I strongly suspect the top level problem area is in:
> mozilla/widget/src/gtk2/nsWindow.cpp - nsWindow::NativeCreate(...)
> between lines ~2825 tto 2897. The lower level calls include such functions
> as:
> gtk_window_new(), gtk_window_group_add_window(), gtk_container_add(),
> gtk_widget_realize() and gtk_window_set_focus(). The problem is that
> ...realize() and ...set_focus() functions are called from other than
> NativeCreate() so debugging it is tricky.
>
> In the course of trying to debug across a Create-TAB request, gdb ended up
> handing me a "Cannot get thread event message: debugger service failed" error.
> Attempts to continue Firefox ended up with a SEGFAULT and core dump (so I've
> lost the error state, though I have the sessionstore.js file for it).
>
> There is some interaction between the Create-TAB request and creating new
> threads so the pthread() library gets dragged into this discussion (along with
> GDK/GTK/GLIB). I think it would help if people also made clear:
> 1) What processor you are using.
> 2) What thread library you are using.
>
> I'm running a Pentium IV (Prescott) which has only 1 core but does support
> hyperthreading. I'm using the most recent release of the Linux Posix pthread
> library (glibc 2.5 I think) and it looks like GLIB is supposed to be using
> pthread_mutex_lock() and pthread_mutex_unlock to get and release locks.
>
> It appears that it may be impossible using gdb (at least on my system) to debug
> pthread_mutex functions (setting breakpoints at them results in the "... thread
> event..." message mentioned previously).
>
> It may be necessary to compile GLIB with G_DEBUG_LOCKS (glib/gthreads.h) and
> set the proper debug flags and/or compile mozilla with MOZ_LOGGING at least for
> the widget/src/gtk2 functions (see #define LOG() in
> widget/src/gtk2/nsCommonWidget.h. Of course adding logging to either the
> widget functions or GLIB may disrupt the timing sufficiently to make the
> problem go away. One thing that appears key is the need to find out where the
> DestroyNotify is coming from (see
> gtk+/gdk/x11/gdkevents-x11.c:gdk_event_translate() -- case DestroyNotify:).
> If your Gtk/Gdk library is compiled with debugging, running Firefox with
> "export GDK_DEBUG=events" may help provide destroy notify messages on the
> console log, but what one really wants is a way to do "_gdk_debug_flags |=
> GDK_DEBUG_EVENTS;" (see GDK_NOTE macro in gdk/gdkinternals.h) after you have
> loaded up all of the windows & tabs that lead up to the problem state.
>
> I hope the above helps to put our hands around the problem.
>

(In reply to comment #31)
> Update.  I strongly suspect the top level problem area is in:
>   mozilla/widget/src/gtk2/nsWindow.cpp - nsWindow::NativeCreate(...)
> between lines ~2825 tto 2897.  The lower level calls include such functions
> as:
> gtk_window_new(), gtk_window_group_add_window(), gtk_container_add(),
> gtk_widget_realize() and gtk_window_set_focus().  The problem is that
> ...realize() and ...set_focus() functions are called from other than
> NativeCreate() so debugging it is tricky.
> 
> In the course of trying to debug across a Create-TAB request, gdb ended up
> handing me a "Cannot get thread event message: debugger service failed" error. 
> Attempts to continue Firefox ended up with a SEGFAULT and core dump (so I've
> lost the error state, though I have the sessionstore.js file for it).
> 
> There is some interaction between the Create-TAB request and creating new
> threads so the pthread() library gets dragged into this discussion (along with
> GDK/GTK/GLIB).  I think it would help if people also made clear:
> 1) What processor you are using.
> 2) What thread library you are using.
> 
> I'm running a Pentium IV (Prescott) which has only 1 core but does support
> hyperthreading.  I'm using the most recent release of the Linux Posix pthread
> library (glibc 2.5 I think) and it looks like GLIB is supposed to be using
> pthread_mutex_lock() and pthread_mutex_unlock to get and release locks.
> 
> It appears that it may be impossible using gdb (at least on my system) to debug
> pthread_mutex functions (setting breakpoints at them results in the "... thread
> event..." message mentioned previously).
> 
> It may be necessary to compile GLIB with G_DEBUG_LOCKS (glib/gthreads.h) and
> set the proper debug flags and/or compile mozilla with MOZ_LOGGING at least for
> the widget/src/gtk2 functions (see #define LOG() in
> widget/src/gtk2/nsCommonWidget.h.  Of course adding logging to either the
> widget functions or GLIB may disrupt the timing sufficiently to make the
> problem go away.  One thing that appears key is the need to find out where the
> DestroyNotify is coming from (see
> gtk+/gdk/x11/gdkevents-x11.c:gdk_event_translate() -- case DestroyNotify:).
> If your Gtk/Gdk library is compiled with debugging, running Firefox with
> "export GDK_DEBUG=events" may help provide destroy notify messages on the
> console log, but what one really wants is a way to do "_gdk_debug_flags |=
> GDK_DEBUG_EVENTS;" (see GDK_NOTE macro in gdk/gdkinternals.h) after you have
> loaded up all of the windows & tabs that lead up to the problem state.
> 
> I hope the above helps to put our hands around the problem.
>

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2007-02-20:

#33

Download full text (4.6 KiB)

Sorry about comment #32. I was trying to correct a spelling error in #31 but there doesn't appear to be an easy way to do that.

Eric, regarding Firefox memory usage, I can kind of explain that problem. I believe that Firefox does have garbage collection for Java and perhaps Javascript. However everything else, the image management, the TCP/IP management, the window and tab management, etc. seem to all be written in C++ and C. So those will normally go through the C++: new()/delete() functions, or C: malloc()/free() functions. These all end up on normal Linux systems using the "standard" GNU glibc memory management functions which in turn rely upon the standard Linux(UNIX) sbrk() and brk() system calls.

The Glibc memory management function system *is* robust (I think it is 90+ pages of code). The problem is that it was not designed to handle situations of "run-for-days" allocating and deallocating many small memory fragments. Once you allocate such memory (in C++ or C) its location has to remain fixed in the virtual memory address space. Over time that means that the heap memory becomes increasingly fragmented (lots of little small holes) and total memory usage tends to creep up. This isn't the same as a "memory leak" where you are losing track of the memory. The glibc memory management system *knows* where all the small fragments are -- the problem is it can't relocate the in use fragments (defragment the heap) to turn all of the unused small fragments into a single large free fragment (preferably at the end of the virtual address space) which could then be returned to Linux (and shrink your VM memory requirements). In contrast, I believe Java, and perhaps Javascript, are sufficiently object oriented that you can relocate objects and perform garbage collection thus preventing the problem of excessive memory fragmentation in their heaps.

In practice, if you watch what Firefox is doing on the System Monitor you may sometimes see VM shrink if you open a window, open lots of tabs in it and then close that window, particularly if you have opened all of those tabs sometime previously. But if they are "new" URLs, then those records may get added to your history list (which may be at the end of Virtual Memory). In this case you can delete the window and the memory will be returned to glibc pool but because the history records are locking up the end of the glibc pool, glibc will not return the memory to Linux. In practice you only see VM shrink at the very end of an normal "Quit" request when Firefox has closed all of the windows, closed the bookmarks file, closed the history file, closed all TCP/IP handles, i.e. freed up *all* of the memory in the glibc memory pool. Only when all of the memory in the heap is completely free will the glibc memory allocator reunite it all as one big hunk of free memory and return it all to Linux (in practice this is done by issuing a brk() system call to lower the last physical address of the process heap).

The "right" way to make this problem better is to put (a) the history records; (b) the Bookmarks file; and (c) image files into separately managed heaps away from the glibc functions (so glibc is ...

Sorry about comment #32. I was trying to correct a spelling error in #31 but there doesn't appear to be an easy way to do that.

Eric, regarding Firefox memory usage, I can kind of explain that problem.  I believe that Firefox does have garbage collection for Java and perhaps Javascript.  However everything else, the image management, the TCP/IP management, the window and tab management, etc. seem to all be written in C++ and C.  So those will normally go through the C++: new()/delete() functions, or C: malloc()/free() functions.  These all end up on normal Linux systems using the "standard" GNU glibc memory management functions which in turn rely upon the standard Linux(UNIX) sbrk() and brk() system calls.

The Glibc memory management function system *is* robust (I think it is 90+ pages of code).  The problem is that it was not designed to handle situations of "run-for-days" allocating and deallocating many small memory fragments.  Once you allocate such memory (in C++ or C) its location has to remain fixed in the virtual memory address space.  Over time that means that the heap memory becomes increasingly fragmented (lots of little small holes) and total memory usage tends to creep up.  This isn't the same as a "memory leak" where you are losing track of the memory.  The glibc memory management system *knows* where all the small fragments are -- the problem is it can't relocate the in use fragments (defragment the heap) to turn all of the unused small fragments into a single large free fragment (preferably at the end of the virtual address space) which could then be returned to Linux (and shrink your VM memory requirements).  In contrast, I believe Java, and perhaps Javascript, are sufficiently object oriented that you can relocate objects and perform garbage collection thus preventing the problem of excessive memory fragmentation in their heaps.

In practice, if you watch what Firefox is doing on the System Monitor you may sometimes see VM shrink if you open a window, open lots of tabs in it and then close that window, particularly if you have opened all of those tabs sometime previously.  But if they are "new" URLs, then those records may get added to your history list (which may be at the end of Virtual Memory).  In this case you can delete the window and the memory will be returned to glibc pool but because the history records are locking up the end of the glibc pool, glibc will not return the  memory to Linux.  In practice you only see VM shrink at the very end of an normal "Quit" request when Firefox has closed all of the windows, closed the bookmarks file, closed the history file, closed all TCP/IP handles, i.e. freed up *all* of the memory in the glibc memory pool.  Only when all of the memory in the heap is completely free will the glibc memory allocator reunite it all as one big hunk of free memory and return it all to Linux (in practice this is done by issuing a brk() system call to lower the last physical address of the process heap).

The "right" way to make this problem better is to put (a) the history records; (b) the Bookmarks file; and (c) image files into separately managed heaps away from the glibc functions (so glibc is primarily handling smaller short term data storage requirements associated with the creation of tabs, windows, data being loaded into them, etc.).  I've seen messages indicating that at least some of the Firefox core developers seem to be aware of this (they may need to use the mmap() function under Linux to get separate heaps) but they generally consider that this is either hard (cough) or not worth doing (because its only a problem under Linux???) and doesn't make any difference when users should be upgrading their machines to support more memory anyway... :-( If you google my name + Firefox + memory + heap you can probably find multiple rants by me on this topic on /. and other BBS systems.

It might be possible to adjust the glibc() memory manager to better handle the behavior of Firefox (the code does have ways its behavior can be tuned) but I've never seen any messages about anyone attempting to do this.  If someone wants to play with it... you want to look at .../glibc/glibc-2.#/malloc/ (malloc.c, mtrace.c & arena.c).  You may be able to determine how your system is compiled with something along the lines of "strings /lib/libc.so.6 | egrep "MALLOC_|MMAP_").  Googling might turn up a tutorial or two on how to change the environment variables.

(All opinions are obviously my own...)

(Also, if we are going to start a discussion on Firefox memory allocation I'm sure there are other bugs better qualified for discussion of *that* problem.)

Revision history for this message

In Mozilla Bugzilla #263160, Braden (braden) wrote on 2007-02-20:

#34

FWIW... I'm observing this on a machine with 6 GB of physical memory.

So I am very skeptical that throwing more physical memory at this problem will alleviate it in the least. On the contrary, I'd be more optimistic about a theory that suggested large amounts of physical memory could aggravate the problem. But I don't have one.

That is not to say that fragmentation of the process address space could not be related to this. It does make a certain amount of sense--just considering the fact that this bug seems only to surface after the process has been running for a while. But, please, let's try to avoid clogging this report with *too* much speculation.

Revision history for this message

In Mozilla Bugzilla #263160, Roc-ocallahan (roc-ocallahan) wrote on 2007-02-20:

#35

Robert: thanks for all the info!

My current hypothesis is that window creation is failing somehow and GTK isn't picking it up, or we're not checking GTK results correctly, and then we create another window with the failed window as its parent and this new window ends up as a rogue toplevel window.

So what'd I'd like you (or someone else) to try is setting a breakpoint at nsWindow::NativeCreate after you've received the first "unexpectedly destroyed" message, perhaps conditional on aNativeParent being non-null and aParent being null. When that gets hit, step through and see what happens. In particular see if the parentGdkWindow or the parentGtkContainer is associated with one of the windows that was unexpectedly destroyed.

There are a lot of reports of these "unexpectedly destroyed" messages happening to various apps over the years, but nothing much in the way of information about what causes them or how to resolve them...

Revision history for this message

In Mozilla Bugzilla #263160, Erikred (erikred) wrote on 2007-02-20:

#36

Robert Bradbury, thanks for the lesson on firefox heap management. Great stuff.
I wish I had a better way of finding this kind of information from a web search.
Too many false hits on anything that relates to firefox.

Braden, Robert O'Callahan, Metler, Phil Ringnalda and everyone else:

I should have included you all in the initial kudos. Not that it matters much, I'm a total nobody around here anyway :-). But I'm sure you agree that Bradbury did a great job with his gdb magic.

I'm rooting for you all, unfortunately I'm not capable of contributing much else than anecdotal evidence about the bug.

Revision history for this message

In Mozilla Bugzilla #263160, Braden (braden) wrote on 2007-02-21:

#37

(In reply to comment #24)
> In that call to NativeCreate, aNativeParent is non-null. So we should be
> hitting either
> http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#2722
> or
> http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#2724
> and setting parentGdkWindow or parentGtkContainer to something, which should
> ensure that this window gets created inside some other window.

We hit

2270 else if (aNativeParent && GDK_IS_WINDOW(aNativeParent))

and do

2271 parentGdkWindow = GDK_WINDOW(aNativeParent);

> Can you figure out why it isn't?

Umm... It seems that mWindowType == eWindowType_popup. That doesn't seem right; any idea why might it be happening?

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2007-02-21:

#38

Download full text (4.3 KiB)

Morning update. After the gdb debacle yesterday (gdb needs some work... :-(), I made the following changes.
1) Recompile gtk+ with --enable-debug=all (because GDK_DEBUG wasn't working);
2) Setup firefox-3.0a2 (with all the debug code) to run with:
     export NSPR_LOG_MODULES=Widget:4
     export NSPR_LOG_FILE=nsprlog.txt (= the Netscape error log)
     export GDK_DEBUG=events
     export GOBJECT_DEBUG=objects
       (GOBJECT_DEBUG may not be important for this problem but does seem
        to reveal some interesting problems with GLIB "leftovers" when
        firefox exits).
     firefox-bin 2>firefox.err (= the GDK error log)
3) Run firefox restoring the previous session (which had demonstrated the problem).

Now, the session that first showed the problem had 73 windows & 424 tabs. When gdb went belly up I was up to 76 windows and 438 tabs (demonstrating the tab-start=>"untitled window" problem with some frequency but not every time).

I'm now up to 100 windows and 586 tabs (mainly using random URLs from the first 25 pages of Digg) with firefox-bin consuming 1.1 GiB of VM and 1.2 GiB Mem (is this including page tables???). No problem. I can't push this much further because I normally run firefox with a 1.4 GiB virtual memory limit (ulimit -Sv 1400000) -- due to Firefox's poor handling of memory allocation failures it will likely core dump if I push it to 1.4. (If one allows Firefox VM >> system PysMem (1.5 GiB for me) ==> watch the system turn into a dog -- but this is really a Linux paging problem somewhat aggravated by the Firefox heap management problems so not for this discussion).

Firefox has been running for ~12 hours. I ran it for a while with Java and Javascript disabled (because the logging seems to slow down new tab/window creation), but Javascript is now enabled without making much difference. One difference may be that the AdBlock addon may not have been active in the previous instance when the problem did occur. Noscript is active and is blocking Javascript on most sites (gmail exempted). Gmail works fine (and it tends to be a moderately reliable "helper" (?) in my case to trigger the problem state).

CPU-wise firefox-bin+X are consuming 40-60% of the CPU time.

The debug log files (for NSPR & GDK) are rather large (10's of MB). I am concerned that outputing the debug messages has changed the timing of Firefox+GDK/GTK/GLIB+X just enough to make the problem "disappear".

I'm not sure I understand yet the discussion of the nsWindow code, but would argue that until we know *precisely* where the DestroyNotify is coming from and why it is happening it may be difficult to know whether changing the upper level code has fixed or simply masked the real problem. But given the number (5362) of "Gdk-Message: destroy notify" events I'm seeing in the GDK log file, it isn't going to be as simple setting a breakpoint in gdkevents-x11.c::gdk_event_translate():case DestroyNotify. What one needs is a stack trace for the DestroyNotify that is at the start of the "untitled window" error sequence (which is presumably different from all of the other DestroyNotify stacks). Given the problem of logging perhaps changing subtle timing requi...

Morning update.  After the gdb debacle yesterday (gdb needs some work... :-(), I made the following changes.
1) Recompile gtk+ with --enable-debug=all (because GDK_DEBUG wasn't working);
2) Setup firefox-3.0a2 (with all the debug code) to run with:
     export NSPR_LOG_MODULES=Widget:4
     export NSPR_LOG_FILE=nsprlog.txt (= the Netscape error log)
     export GDK_DEBUG=events
     export GOBJECT_DEBUG=objects
       (GOBJECT_DEBUG may not be important for this problem but does seem
        to reveal some interesting problems with GLIB "leftovers" when
        firefox exits).
     firefox-bin 2>firefox.err (= the GDK error log)
3) Run firefox restoring the previous session (which had demonstrated the problem).

Now, the session that first showed the problem had 73 windows & 424 tabs.  When gdb went belly up I was up to 76 windows and 438 tabs (demonstrating the tab-start=>"untitled window" problem with some frequency but not every time).

I'm now up to 100 windows and 586 tabs (mainly using random URLs from the first 25 pages of Digg) with firefox-bin consuming 1.1 GiB of VM and 1.2 GiB Mem (is this including page tables???).  No problem.  I can't push this much further because I normally run firefox with a 1.4 GiB virtual memory limit (ulimit -Sv 1400000) -- due to Firefox's poor handling of memory allocation failures it will likely core dump if I push it to 1.4.  (If one allows Firefox VM >> system PysMem (1.5 GiB for me) ==> watch the system turn into a dog -- but this is really a Linux paging problem somewhat aggravated by the Firefox heap management problems so not for this discussion).

Firefox has been running for ~12 hours.  I ran it for a while with Java and Javascript disabled (because the logging seems to slow down new tab/window creation), but Javascript is now enabled without making much difference.  One difference may be that the AdBlock addon may not have been active in the previous instance when the problem did occur.  Noscript is active and is blocking Javascript on most sites (gmail exempted).  Gmail works fine (and it tends to be a moderately reliable "helper" (?) in my case to trigger the problem state).

CPU-wise firefox-bin+X are consuming 40-60% of the CPU time.

The debug log files (for NSPR & GDK) are rather large (10's of MB).  I am concerned that outputing the debug messages has changed the timing of Firefox+GDK/GTK/GLIB+X just enough to make the problem "disappear".

I'm not sure I understand yet the discussion of the nsWindow code, but would argue that until we know *precisely* where the DestroyNotify is coming from and why it is happening it may be difficult to know whether changing the upper level code has fixed or simply masked the real problem.  But given the number (5362) of "Gdk-Message: destroy notify" events I'm seeing in the GDK log file, it isn't going to be as simple setting a breakpoint in gdkevents-x11.c::gdk_event_translate():case DestroyNotify.  What one needs is a stack trace for the DestroyNotify that is at the start of the "untitled window" error sequence (which is presumably different from all of the other DestroyNotify stacks).  Given the problem of logging perhaps changing subtle timing requirements for the problem to occur it isn't clear that one could simply stick some stack tracing code into the DestroyNotify code.

Even if one fixes the nsWindow code so it works, that doesn't explain why it works almost all of the time now but fails in these random cases (when the CPU load is too heavy?  when Javascript has fragmented the heap?  when some race condition occurs in GDK/GLIB?)

One question might be whether there is an explicit way when Firefox is running to stop asynchronous activity (e.g. garbage collectors, which I presume are in separate threads)?  (In the fragmented heap situation, I presume that these will contribute to excessive CPU consumption by firefox, so it would be useful to (a) create the problem state; (b) turn off async CPU consuming threads; (c) see if the probability of the problem taking place diminishes).

It would also be nice if there were some in-place hooks so that one could put the stack trace code into the DestroyNotify code, restart firefox with an error-prone session and then hit the process with a SIGUSR1 to activate the DestroyNotify stack tracing after one has encountered the problem the first time.  At least then one would be dealing with perhaps dozens of traces rather than thousands.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2007-02-21:

#39

Created an attachment (id=255907)
Example of Window creation & destruction with NSPR_LOG_MODULES=Widget:4

Example of "normal" window creation & destruction trace (for comparison purposes).

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2007-02-21:

#40

Created an attachment (id=255908)
Example of unusual window destruction case.

This is an example of a window destruction trace which occurs when firefox is "inactive", i.e. no firefox windows or tabs are being manipulated by the keyboard or mouse. If firefox is free to create & destroy windows "behind the scenes" then debugging Bug #263160 is going to be a problem.

Revision history for this message

In Mozilla Bugzilla #263160, Paul Brannan (pbrannan) wrote on 2008-01-19:

#133

> Killing original NY Times home page window (clicking on the window X) deleted
> the original window, the untitled window and the save pop-up window (at least
> there is a work-around). Of course its a bad work around if you have other
> useful tabs in the same window as the one causing the problem (though I
> believe killing the dysfunctional tab might have worked).

Usually killing the tab also destroys the unwanted window, for me. Sometimes it takes down firefox, but I think that's because this bug is usually triggered in low-memory situations.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-01-19:

#134

The NY Times javacript timeout function appears to be the file:
http://graphics8.nytimes.com/js/home/screen/common.js
I fetched it using "wget".

It looks like it times out every 15 minutes. I still haven't figured where it
gets called from (perhaps it is simply setup when the common.js file is loaded from the home page). It gives you a good idea of how to setup the timeouts
using Javascript (which I don't speak).

Since Javacript appears to have a millisecond timer vs. HTML which uses seconds
one ought to be able to max out the machine by having a function like the NY
Times timer function deduct start with a 5 second refresh then deduct 10-100
milliseconds for each successive refresh until the machine gets maxed out.

Revision history for this message

In Mozilla Bugzilla #263160, Roc-ocallahan (roc-ocallahan) wrote on 2008-01-20:

#135

There are so many comments here that it's going to be hard to get anything done.

What we need here is a testcase that will reproduce the bug, not just for one person but for many or hopefully all people. This may involve writing HTML or possibly even using a Python web server. Or you may be able to get away with enabling popups and using window.open and document.write. Please lets focus on that and not discuss the details of hardware configurations or speculate about what might be causing the bug.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-01-21:

#136

Please note Bug #413390 and the NYT-test.sh attachment to it. In a perfect world, i.e. if Firefox could launch tabs until ones swap space was exhausted, I suspect that script (or multiple invocations thereof) would in fact provide the test case ":roc" desires. The script might provide a test case if one increases MAXSESSIONS to 250+ and increases INTERVAL to 30+ but it is going to require running the script for several hours to generate a sufficient number of tabs (running a sufficient number of page refreshes) that an "untitled window" may appear.

I suspect, the INTERVAL and MAXSESSIONS are going to be highly CPU dependent. The goal is to generate a sufficiently large number of asynchronous Javascript timeouts running such that one or more timeouts will expire in the middle of a previous page refresh (delete and redraw) operation has completed. This leading to the GDK errors and the "untitled window".

To the best of my knowledge there is no way to obtain a "ps" within Firefox for currently pending Javascript timeouts. This is another "bug".

Revision history for this message

In Mozilla Bugzilla #263160, Mook-moz+mozbz (mook-moz+mozbz) wrote on 2008-02-21:

#137

*** Bug 365734 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Antoine-mechelynck-gmail (antoine-mechelynck-gmail) wrote on 2008-03-23:

#138

*** Bug 367832 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-04-04:

#139

Please note the creation of Bug #427024, using a very recent release of Firefox 3.0pre. That bug provides both a sessionstore.js file and firefox log files for a reproducible (at least within an existing firefox session) for the "window unexpectedly destroyed" and the "untitled window" problems using Gmail, which means the problem is being generated using Javascript -- this is slightly different from many of the problems reported under this bug which are typically generated by window redraw commands from HTTP timeouts (sometimes used by news providers, advertisers, etc.).

Revision history for this message

In Mozilla Bugzilla #263160, Antoine-mechelynck-gmail (antoine-mechelynck-gmail) wrote on 2008-04-19:

#140

*** Bug 399436 has been marked as a duplicate of this bug. ***

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-04-24:

#141

Created an attachment (id=317518)
GDB log of window unexpectedly destroyed errors

Ok, here you go, finally after more than a year of encountering this problem is a set of stack traces. This is a "current" firefox (CVS compiled 29 Mar 08 / version 3.0pre). Firefox itself, gdk+, glib and libc are compiled with debug symbols (-g2).

The firefox session has been running 3 days (when the system was rebooted). It was a restart of a previous long running session so it currently has 53 windows and 445 tabs open.

The problem is gmail is completely dysfunctional! The symptoms first appeared as an old (working) gmail window could not compose a message. One could enter the To: line and the Subject: line but the window would fail to echo text typed into the main body message. One could discard the partial message and start a new message and it exhibited the same problem. One could close the old gmail window and attempt to reopen a new gmail window and that would produce the standard "GdkWindow ... unexpectedly destroyed" messages *consistantly*. There are 14 GdkWindow warnings followed by 3 gdk_x11_visual_get_xvisual warnings. I presume these are due to the initial Gmail Javascript setup code.

It should be noted that a gmail "window" is displayed, with a title "Gmail - Inbox(4) - <email address hidden> - Mozilla Firefox" but no text is displayed within the window.

The debugger was attached to firefox, some breakpoints were set and deleted when they were determined to be too "chatty". The last ~18 backtraces involved the g_log messages resulting from a fresh gmail window restart.

I will attempt to keep this firefox/gdb session open in the hope that someone who understands widget/src/gtk2/nsWindow.cpp : nsWindow::Destroy() (and the gtk/glib code) will contact me so this problem can finally be debugged.

It should be noted, that even with a troublesome sessionstore.js file (many windows and tabs) it still usually takes several days of use to get Firefox into the window destroying problem state.

Created an attachment (id=317518)
GDB log of window unexpectedly destroyed errors

Ok, here you go, finally after more than a year of encountering this problem is a set of stack traces.  This is a "current" firefox (CVS compiled 29 Mar 08 / version 3.0pre).  Firefox itself, gdk+, glib and libc are compiled with debug symbols (-g2).

The firefox session has been running 3 days (when the system was rebooted).  It was a restart of a previous long running session so it currently has 53 windows and 445 tabs open.

The problem is gmail is completely dysfunctional!  The symptoms first appeared as an old (working) gmail window could not compose a message.  One could enter the To: line and the Subject: line but the window would fail to echo text typed into the main body message.  One could discard the partial message and start a new message and it exhibited the same problem.  One could close the old gmail window and attempt to reopen a new gmail window and that would produce the standard "GdkWindow ... unexpectedly destroyed" messages *consistantly*.  There are 14 GdkWindow warnings followed by 3 gdk_x11_visual_get_xvisual warnings.  I presume these are due to the initial Gmail Javascript setup code.

It should be noted that a gmail "window" is displayed, with a title "Gmail - Inbox(4) - robert.bradbury@gmail.com - Mozilla Firefox" but no text is displayed within the window.

The debugger was attached to firefox, some breakpoints were set and deleted when they were determined to be too "chatty".  The last ~18 backtraces involved the g_log messages resulting from a fresh gmail window restart.

I will attempt to keep this firefox/gdb session open in the hope that someone who understands widget/src/gtk2/nsWindow.cpp : nsWindow::Destroy() (and the gtk/glib code) will contact me so this problem can finally be debugged.

It should be noted, that even with a troublesome sessionstore.js file (many windows and tabs) it still usually takes several days of use to get Firefox into the window destroying problem state.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-04-24:

#142

Created an attachment (id=317520)
Window destroyed problems opening new tabs

Ok, here are the Firefox traces from the same problematic firefox session. In this case however, the problem is not gmail, instead it is opening new tabs from http://www.sciencedaily.com/. There was a previous window with tabs open to the sciencedaily home page. Sciencedaily is normally accessed with Noscript on (so there should be no Javascript running from that site). Various URLs from the home page were right-clicked and opened in a new tab. Each of these results in a single window unexpectedly destroyed breakpoint & message. It appears that it is complaining about the window normally opened when one right-clicks on a URL as the breakpoint/message occurs after that window is opened & closed but before the new tab associated with the new URL is created.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-04-24:

#143

Regarding the "semi-responsiveness" of hung gmail window (mentioned in Attachment #317518).

It may be worth noting that although the Firefox gmail window contents is "dead" (i.e. the window body displays the contents of what was previously at that location on the monitor), it is still "alive".

One can move the window around on the monitor, can move it between workspaces and interestingly enough it is still communicating with gmail. If I use Galeon to access my gmail mailbox and send myself a test message the title bar on the window does change from 4 unread messages to 5 unread messages. The time for this to happen however is some number of seconds, significantly longer than for the same change to be reflected in the Galeon window for my mailbox.

Revision history for this message

sra136 (sra136) wrote on 2008-05-04:

#144

Binary package hint: firefox-3.0

With some websites, a "Untitled window" that pops up. Closing the window will close the browser.

ProblemType: Bug
Architecture: i386
Date: Sun May 4 08:58:33 2008
DistroRelease: Ubuntu 8.04
Package: firefox-3.0 3.0~b5+nobinonly-0ubuntu3
PackageArchitecture: i386
ProcEnviron:
PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-17-generic i686

Revision history for this message

sra136 (sra136) wrote on 2008-05-04:

#145

Dependencies.txt Edit (2.6 KiB, text/plain; charset="utf-8")
pluginreg.dat.txt Edit (2.5 KiB, text/plain; charset="utf-8")
profiles.ini.txt Edit (94 bytes, text/plain; charset="utf-8")

Revision history for this message

Joe Smith (yasumoto7) wrote on 2008-05-06:

#146

Could you give an example of a site where this occurs?

Revision history for this message

Arthur (moz-liebesgedichte) wrote on 2008-05-23:

#147

I've had this happen on tagi.ch several times today now. I've never seen it before. Probably advertisers have changed their popup-scripts. Bug #227068 sounds similar.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-05-24:

#148

Download full text (4.2 KiB)

Ok, hear is the stack trace from an "unexpectedly destroyed" in the context of returning from a gmail message back to the Inbox index error:

Breakpoint 1, IA__g_logv (log_domain=0xb79e98f4 "Gdk", log_level=G_LOG_LEVEL_CRITICAL,
format=0xb783deec "%s: assertion `%s' failed", args1=0xbfb43510 "x�� \b") at gmessages.c:396
396 gboolean was_fatal = (log_level & G_LOG_FLAG_FATAL) != 0;
(gdb) thread apply bt all
(gdb) thread apply all bt

Thread 7 (Thread 0xb67a8b90 (LWP 12544)):
#0 0xb7f83410 in __kernel_vsyscall ()
#1 0xb71e65b7 in *__GI___poll (fds=0xb67a7f98, nfds=2, timeout=65535000)
at ../sysdeps/unix/sysv/linux/poll.c:87
#2 0xb7dffe5a in PR_Poll () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3 0x080d0a0c in ?? ()
#4 0x08cbd450 in ?? ()
#5 0x00000002 in ?? ()
#6 0x03e7fc18 in ?? ()
#7 0xb7dfe516 in PR_ExitMonitor () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#8 0x080d137d in ?? ()
#9 0x08cbcf70 in ?? ()
#10 0x00000001 in ?? ()
#11 0xb67a8208 in ?? ()
#12 0xb7eb7ff4 in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#13 0x08cbd7b8 in ?? ()
#14 0x00000001 in ?? ()
#15 0xb67a8218 in ?? ()
#16 0xb7e81dd7 in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#17 0x08cbd7d8 in ?? ()
#18 0x00000000 in ?? ()

Thread 6 (Thread 0xb5f75b90 (LWP 12545)):
#0 0xb7f83410 in __kernel_vsyscall ()
#1 0xb7f73b12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2 0xb7dfd3a5 in ?? () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3 0x08c3497c in ?? ()
#4 0x08c58410 in ?? ()
#5 0xb5f7528c in ?? ()
#6 0xb7f745f5 in __pthread_getspecific (key=93793) at pthread_getspecific.c:27
#7 0xb7dfe194 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#8 0xb7e8646f in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#9 0x08c34978 in ?? ()
#10 0x00051fb9 in ?? ()
#11 0x08c58410 in ?? ()
#12 0xb7eb7ff4 in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#13 0x08e2a420 in ?? ()
#14 0x00000000 in ?? ()

Thread 5 (Thread 0xb4679b90 (LWP 12549)):
#0 0xb7f83410 in __kernel_vsyscall ()
#1 0xb7f737e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2 0xb7dfe226 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3 0x088daa5a in ?? ()
#4 0x090aeb18 in ?? ()
#5 0xffffffff in ?? ()
#6 0xb1c8b2f0 in ?? ()
#7 0xb1746cb0 in ?? ()
#8 0x08bff4a8 in ?? ()
#9 0x00000000 in ?? ()

Thread 4 (Thread 0xb4e7ab90 (LWP 12550)):
#0 0xb7f83410 in __kernel_vsyscall ()
#1 0xb7f737e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2 0xb7dfe226 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3 0x088c6de3 in ?? ()
#4 0x09290278 in ?? ()
#5 0xffffffff in ?? ()
#6 0x092901dc in ?? ()
#7 0xb7e0cff4 in ?? () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#8 0x092902b8 in ?? ()
#9 0x00000000 in ?? ()

Thread 3 (Thread 0xb2593b90 (LWP 12563)):
#0 0xb7f83410 in __kernel_vsyscall ()
#1 0xb7f737e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2 0xb7dfe226 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3 0xb7dfe287 in PR_Wait () from /...

Ok, hear is the stack trace from an "unexpectedly destroyed" in the context of returning from a gmail message back to the Inbox index error:

Breakpoint 1, IA__g_logv (log_domain=0xb79e98f4 "Gdk", log_level=G_LOG_LEVEL_CRITICAL, 
    format=0xb783deec "%s: assertion `%s' failed", args1=0xbfb43510 "x���� ��\b") at gmessages.c:396
396	  gboolean was_fatal = (log_level & G_LOG_FLAG_FATAL) != 0;
(gdb) thread apply bt all
(gdb) thread apply all bt

Thread 7 (Thread 0xb67a8b90 (LWP 12544)):
#0  0xb7f83410 in __kernel_vsyscall ()
#1  0xb71e65b7 in *__GI___poll (fds=0xb67a7f98, nfds=2, timeout=65535000)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#2  0xb7dffe5a in PR_Poll () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3  0x080d0a0c in ?? ()
#4  0x08cbd450 in ?? ()
#5  0x00000002 in ?? ()
#6  0x03e7fc18 in ?? ()
#7  0xb7dfe516 in PR_ExitMonitor () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#8  0x080d137d in ?? ()
#9  0x08cbcf70 in ?? ()
#10 0x00000001 in ?? ()
#11 0xb67a8208 in ?? ()
#12 0xb7eb7ff4 in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#13 0x08cbd7b8 in ?? ()
#14 0x00000001 in ?? ()
#15 0xb67a8218 in ?? ()
#16 0xb7e81dd7 in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#17 0x08cbd7d8 in ?? ()
#18 0x00000000 in ?? ()

Thread 6 (Thread 0xb5f75b90 (LWP 12545)):
#0  0xb7f83410 in __kernel_vsyscall ()
#1  0xb7f73b12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2  0xb7dfd3a5 in ?? () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3  0x08c3497c in ?? ()
#4  0x08c58410 in ?? ()
#5  0xb5f7528c in ?? ()
#6  0xb7f745f5 in __pthread_getspecific (key=93793) at pthread_getspecific.c:27
#7  0xb7dfe194 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#8  0xb7e8646f in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#9  0x08c34978 in ?? ()
#10 0x00051fb9 in ?? ()
#11 0x08c58410 in ?? ()
#12 0xb7eb7ff4 in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#13 0x08e2a420 in ?? ()
#14 0x00000000 in ?? ()

Thread 5 (Thread 0xb4679b90 (LWP 12549)):
#0  0xb7f83410 in __kernel_vsyscall ()
#1  0xb7f737e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2  0xb7dfe226 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3  0x088daa5a in ?? ()
#4  0x090aeb18 in ?? ()
#5  0xffffffff in ?? ()
#6  0xb1c8b2f0 in ?? ()
#7  0xb1746cb0 in ?? ()
#8  0x08bff4a8 in ?? ()
#9  0x00000000 in ?? ()

Thread 4 (Thread 0xb4e7ab90 (LWP 12550)):
#0  0xb7f83410 in __kernel_vsyscall ()
#1  0xb7f737e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2  0xb7dfe226 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3  0x088c6de3 in ?? ()
#4  0x09290278 in ?? ()
#5  0xffffffff in ?? ()
#6  0x092901dc in ?? ()
#7  0xb7e0cff4 in ?? () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#8  0x092902b8 in ?? ()
#9  0x00000000 in ?? ()

Thread 3 (Thread 0xb2593b90 (LWP 12563)):
#0  0xb7f83410 in __kernel_vsyscall ()
#1  0xb7f737e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/local/lib/libpthread.so.0
#2  0xb7dfe226 in PR_WaitCondVar () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#3  0xb7dfe287 in PR_Wait () from /usr/local/lib/firefox-3.0pre/libnspr4.so
#4  0xb7e812f5 in nsEventQueue::GetEvent () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#5  0xb7e8243d in ?? () from /usr/local/lib/firefox-3.0pre/libxpcom_core.so
#6  0x09eb3868 in ?? ()
#7  0x00000001 in ?? ()
#8  0xb2593314 in ?? ()
#9  0x00000000 in ?? ()

Thread 1 (Thread 0xb6eca6d0 (LWP 12543)):
#0  IA__g_logv (log_domain=0xb79e98f4 "Gdk", log_level=G_LOG_LEVEL_CRITICAL, 
    format=0xb783deec "%s: assertion `%s' failed", args1=0xbfb43510 "x���� ��\b") at gmessages.c:396
#1  0xb77ed9b9 in IA__g_log (log_domain=0xb79e98f4 "Gdk", log_level=G_LOG_LEVEL_CRITICAL, 
    format=0xb783deec "%s: assertion `%s' failed") at gmessages.c:517
#2  0xb77edbfc in IA__g_return_if_fail_warning (log_domain=0xb79e98f4 "Gdk", 
    pretty_function=0xb7a0ae78 "gdk_window_set_back_pixmap", expression=0xb7a020b3 "GDK_IS_WINDOW (window)")
    at gmessages.c:532
#3  0xb79de9c2 in IA__gdk_window_set_back_pixmap (window=0x0, pixmap=0x0, parent_relative=0)
    at gdkwindow-x11.c:3059
#4  0x08268ecb in ?? ()
#5  0x00000000 in ?? ()

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-05-24:

#149

Another example with clearer traces:
(the former may involve extended Glib errors while this involves current glib errors.

Breakpoint 1, IA__g_logv (log_domain=0xb79e98f4 "Gdk", log_level=G_LOG_LEVEL_WARNING,
    format=0xb7a0a2e4 "GdkWindow %#lx unexpectedly destroyed",
    args1=0xbfb43cfc "?M?\001\210??\0368??\b\v\023\236?????\001") at gmessages.c:396
396 gboolean was_fatal = (log_level & G_LOG_FLAG_FATAL) != 0;
(gdb) bt
#0 IA__g_logv (log_domain=0xb79e98f4 "Gdk", log_level=G_LOG_LEVEL_WARNING,
    format=0xb7a0a2e4 "GdkWindow %#lx unexpectedly destroyed",
    args1=0xbfb43cfc "?M?\001\210??\0368??\b\v\023\236?????\001") at gmessages.c:396
#1 0xb77ed9b9 in IA__g_log (log_domain=0xb79e98f4 "Gdk", log_level=G_LOG_LEVEL_WARNING,
    format=0xb7a0a2e4 "GdkWindow %#lx unexpectedly destroyed") at gmessages.c:517
#2 0xb79e1477 in IA__gdk_window_destroy_notify (window=0x206e51e8) at gdkwindow-x11.c:1222
#3 0xb79c6c68 in gdk_event_translate (display=0x8c18018, event=0x2211c2e8, xevent=0xbfb43e5c,
    return_exposes=0) at gdkevents-x11.c:1744
#4 0xb79c82d7 in _gdk_events_queue (display=0x8c18018) at gdkevents-x11.c:2285
#5 0xb79c879f in gdk_event_dispatch (source=0x8c1f188, callback=0, user_data=0x0) at gdkevents-x11.c:2345
#6 0xb77e47f8 in IA__g_main_context_dispatch (context=0x8c1f1d0) at gmain.c:2009
#7 0xb77e7a4e in g_main_context_iterate (context=0x8c1f1d0, block=0, dispatch=1, self=0x8c01c48)
    at gmain.c:2642
#8 0xb77e7f9c in IA__g_main_context_iteration (context=0x8c1f1d0, may_block=0) at gmain.c:2705
#9 0x08246aec in ?? ()
#10 0x00000000 in ?? ()

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-05-24:

#150

My recent file bug reports on this bug have been generated by Gnail which seems adept at generating this bug under heavy load conditions (i.e. 277+ active tabs in the browser).

And so I am saying to the people who wish to verify firefox functionality -- you will not know it until you test it. My Gmail problems do not seem to appear until I have multiple sites active.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-05-24:

#151

Let us seriously discuss this question. The bug has been here for 4+ years and has still not been resolved, Therefore it must be an issue between the Mozilla developers and the X developers -- who do not choose to cross-pollinate with respect to potential X-bugs. OR we must generally consent to the fact that the masses are generally immune to Linux and proceed along their general way.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-05-25:

#152

As this has been a Firefox bug for 4+ years and is still unresolved, I feel compelled to point out that it appears in relatively static mode with respect the glib stack dumps and their position.

The fundamental problem appears to be 'do this operation on window X when window X and its subunits have been deleted''

That requires a commitment from the release "gods" of firefox 3.0 that they will not release it with "known bugs on deck" It is insufficient if a program can be claimed to work for Windows and not for Linux. IMO, that is a non-functionable.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-05-25:

#153

Created an attachment (id=322449)
Set of gdb stack traces of destroyed windows

Here is a set of gdb stack traces of firefox throwing the "window unexpectedly destroyed" bug (plus a few other glib errors). The URLs involved were gmail (searching ones own mailbox) and the Internet Movie Database (www.imdb.com).

I've got a firefox setup *NOW* which is regularly throwing these errors into gdb. It will not get resolved until someone, presumably someone who understands Firefox's javascript enabled use of windows timers, creation and destruction, contacts me for further information.

I can verify that this is currently the *real* bug, because in gmail when it is throwing bugs I see it create and subsequently delete the little untitled windows before it returns to the main screen.

Revision history for this message

Alexander Sack (asac) wrote on 2008-05-29: Re: [Bug 226470] Re: untitled popup window

#154

On Fri, May 23, 2008 at 08:29:31AM -0000, Arthur wrote:
> I've had this happen on tagi.ch several times today now. I've never seen
> it before. Probably advertisers have changed their popup-scripts. Bug
> #227068 sounds similar.
>

Please attach a screenshot of that situation.

status incomplete

Thanks,

- Alexander

Changed in firefox-3.0:
status:	New → Incomplete

Revision history for this message

Arthur (moz-liebesgedichte) wrote on 2008-05-30:

#155

It's as mysteriously gone as it came... I haven't seen it now for several days. Really weird.

Revision history for this message

Alexander Sack (asac) wrote on 2008-05-30:

#156

On Fri, May 30, 2008 at 07:50:59AM -0000, Arthur wrote:
> It's as mysteriously gone as it came... I haven't seen it now for
> several days. Really weird.
>

OK thanks. If you see it again, please reopen this bug.

status invalid

- Alexander

Changed in firefox-3.0:
status:	Incomplete → Invalid

Revision history for this message

Arthur (moz-liebesgedichte) wrote on 2008-05-30:

#157

Screenshot.png Edit (386.9 KiB, image/png)

Speaking of the devil... Today it showed up again. This time under nzz.ch. See attached screenshot.

Changed in firefox-3.0:
status:	Invalid → New

Revision history for this message

Alexander Sack (asac) wrote on 2008-06-02:

#158

On Fri, May 30, 2008 at 01:03:41PM -0000, Arthur wrote:
> Speaking of the devil... Today it showed up again. This time under
> nzz.ch. See attached screenshot.
>

Can you reproduce? maybe uninstalling flash helps? maybe disabling
your extensions in tools -> addons helps?

status incomplete

- Alexander

Changed in firefox-3.0:
status:	New → Incomplete

Revision history for this message

Arthur (moz-liebesgedichte) wrote on 2008-06-02:

#159

I'm pretty sure it's triggered by certain adds which unfortunately change each time you load the page. I'll try to see what triggers it, but that can take its time as they are rather infrequent. By the way I've only ever seen this with the Ubuntu FF3 Beta 5, never with the current mozilla.org nightlies.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-06-03:

#160

It also may be of use to look at Bug #437021 which is a distinct bug of its own because it relates to Firefox SEGFAULTing under Linux (repeatable as I have 5+ traces involving the problem with the associated crashes of Firefox), only the most recent of which involved getting a gdb trace. But Firefox *was* in the state where it was repeatedly throwing the "window unexpectedly destroyed" messages and it was being generated usually from "gmail" which probably means an improperly handled Javascript window timeout (or destruction) problem.

Revision history for this message

Alexander Sack (asac) wrote on 2008-06-05: Re: [Bug 226470] Re: untitled popup window

#161

On Mon, Jun 02, 2008 at 08:57:26PM -0000, Arthur wrote:
> I'm pretty sure it's triggered by certain adds which unfortunately
> change each time you load the page. I'll try to see what triggers it,
> but that can take its time as they are rather infrequent. By the way
> I've only ever seen this with the Ubuntu FF3 Beta 5, never with the
> current mozilla.org nightlies.
>

I assume those are flash adds. Try to remove the adobe flash player
and install mozilla-plugin-gnash player for instance.

affects ubuntu/firefox-3.0
status invalid

affects ubuntu/flashplugin-nonfree
status incomplete

- Alexander

Changed in firefox-3.0:
status:	Incomplete → Invalid

Revision history for this message

gua (gua) wrote on 2008-06-27:

#162

Been having the same issue since starting on Ubuntu 7.04 and Firefox 2.0

Apparently it's caused by a number of things and it's tied to Gnome

Read more:
https://bugzilla.mozilla.org/show_bug.cgi?id=263160

Revision history for this message

In Mozilla Bugzilla #263160, Cameron McCormack (cam-mcc) wrote on 2008-07-15:

#163

I used to get this kind of behaviour before Firefox 3, where occasionally I'd get a tab's frame open in a separate top-level window (with no window title, and strangely isn't focussable -- using Sawfish as my window manager). Since Firefox 3 I don't get this as much, but I have noticed it happening with Flash sometimes. I have the FlashBlock extension running. Sometimes the new top-level window has the Flash object running in it (despite the fact that the replacement graphic in the main page's window is showing), and sometimes it is an empty, grey window. Sorry I haven't got any more useful information to provide.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-12-07:

#164

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.

Revision history for this message

In Mozilla Bugzilla #263160, L. David Baron (dbaron) wrote on 2008-12-07:

#165

(In reply to comment #152)
> 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.

As I said in comment 78, all of Mozilla's interaction with GTK/Gdk/X11 is on a single thread.

Revision history for this message

In Mozilla Bugzilla #263160, Erikred (erikred) wrote on 2008-12-23:

#166

David Baron,

But what if one has multiple firefoxes all pounding on GTK/Gdk/X11 at the same time? Could that be part of the problem? I just got an Untitled window again, this time in Fedora 10 64b with 5 instances of firefox 3.0.4 running and maybe 500 tabs altogether,

On a possibly related note, in fedora 10 my X11 process has been going wild using up 11-12G of main memory, and there appears to be a correlation with whether the browsers are started sequentially/gradually or all loaded up at once (maximum stress on GTK/Gdl/X11 window system). This is with Nvidia Geforce6100 or 7200, and either the public (aka. nv) or the proprietary (aka. nvidia) driver.

Revision history for this message

In Mozilla Bugzilla #263160, Robert-bradbury (robert-bradbury) wrote on 2008-12-24:

#167

Erik/David, related to your comments regarding the problem, see my comments on Bug #467744 # 6.

Regarding David's claims that the GDK access is single threaded (I want the function names that insure this.) I have been reading C since 1974, I have actually met both Dennis Ritchie and Ken Thompson at various points. You can claim crap but this is a "trust but verify world". One of the shortcomings IMO for the mozilla perspective is that the do *NOT* have a perspective for bringing one "up-to-speed".

Getting back to Erik's points, there is a question of whether or not asynchronous processes (threads) get to address the display manager (GDK). Given his many valid points about when and how the display manager may be addressed, is the issue of how one is managing that. (Note I do not see messages between the Firefox developers and the GDK/GTK developers) revealing that they might understand the capabilities and limits of their software systems. (Which when you are attempting to operate on a deleted window -- clearly show you do not understand.)

Revision history for this message

In Mozilla Bugzilla #263160, Karlt (karlt) wrote on 2009-05-25:

#168

I'd expect this to result from http://bugzilla.gnome.org/show_bug.cgi?id=581526

Changes to gdk_window_new before gtk+-2.14.0 would have meant that the crash of bug 467744 resulted instead:
http://git.gnome.org/cgit/gtk+/commit/?h=gtk-2-14&id=4111cf2065e1f7edc614a936f1fa35e750f13a0f

But gtk+-2.15.1 and newer will probably start showing these symptoms again as the crash of bug 467744 is patched up here:
http://git.gnome.org/cgit/gtk+/commit/?h=gtk-2-16&id=27d8d8ea2bb815df0733f5d4d57d93542e2c160a

Revision history for this message

In Mozilla Bugzilla #263160, Ovemen (ovemen) wrote on 2009-06-10:

#169

Download full text (9.7 KiB)

It used to happen to me every time on RH9 and FC6, using Firefox 1.5 (and I believe also 2.0), after the browser was used for a day or so.

Now, with FC6, FF 3.0.10 it doesn't happen very often, but it happens, especially recently.

** (evince:16737): WARNING **: Unimplemented named action: POPPLER_DEST_FITBH, please post a bug report in Evince bugzilla (http://bugzilla.gnome.org) with a testcase.

(Gecko:28775): Gtk-CRITICAL **: gtk_drag_set_icon_pixbuf: assertion `GDK_IS_DRAG_CONTEXT (context)' failed

(Gecko:28775): Gdk-WARNING **: GdkWindow 0x28d6e54 unexpectedly destroyed

(Gecko:28775): Gdk-WARNING **: GdkWindow 0x28d6e47 unexpectedly destroyed

(Gecko:28775): Gdk-WARNING **: GdkWindow 0x28d664f unexpectedly destroyed

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

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

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

(Gecko:28775): Gdk-CRITICAL **: gdk_x11_visual_get_xvisual: assertion `visual != NULL' failed

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

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

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

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

(Gecko:28775): Gdk-WARNING **: GdkWindow 0x28d6650 unexpectedly destroyed