untitled popup window

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

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>

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.

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/

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.

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

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

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

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

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

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

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.

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?

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..."

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.

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

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

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

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.

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.

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 ?

I'll give it a shot.

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.

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?

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

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.

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

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.

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...

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.

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.

(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.
>

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 ...

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.

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...

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.

(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?

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...

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).

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.

> 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.

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.

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.

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".

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

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

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.).

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

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=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.

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.

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 /...

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 ?? ()

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.

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.

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.

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.

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.

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.

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.

(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.

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.

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.)

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

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.

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

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

** (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): 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

(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): 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 0x28d6653 unexpectedly destroyed

(Gecko:28775): Gdk-CRITICAL **: gdk_window_set_user_data: as...

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

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

> sometimes it is an empty, grey window

Same here, with Ubuntu 12.04 LTS Unity 2d