Bug 193274

This problem came up again.  Closing the window-that-should-not-be seems to
crash Firefox, so I again applied gdb to the firefox process before closing the
window.

I put breakpoints at exit and _exit in hopes of getting control before the
process disappeared.

After setting the breakpoints, but before telling gdb to "continue", I closed
the extraneous window.  Much to my surprise, all the firefox windows closed,
even though the process should have been suspended/paused via gdb's ptrace.  I
guess that this is due to threads, something I don't know much about.

Anyway, when I then issued the "continue" command, the process (thread?)
immediately stopped and gdb showed:
  Program received signal SIGPIPE, Broken pipe.
  [Switching to Thread 46912501253888 (LWP 27145)]
  0x0000003e9e20bedb in __write_nocancel () from /lib64/libpthread.so.0

Here's what "where" says:
(gdb) where
#0  0x0000003e9e20bedb in __write_nocancel () from /lib64/libpthread.so.0
#1  0x0000003e9de4626f in _X11TransGetConnectionNumber () from
/usr/lib64/libX11.so.6
#2  0x0000003e9de4b2df in _XSend () from /usr/lib64/libX11.so.6
#3  0x0000003e9de4b411 in _XReply () from /usr/lib64/libX11.so.6
#4  0x0000003e9de921f1 in XkbGetState () from /usr/lib64/libX11.so.6
#5  0x0000003ea1c4d79a in gdk_keymap_get_entries_for_keyval () from
/usr/lib64/libgdk-x11-2.0.so.0
#6  0x0000003ea1c4da2e in gdk_keymap_get_direction () from
/usr/lib64/libgdk-x11-2.0.so.0
#7  0x0000003ea1c45078 in gdk_events_pending () from /usr/lib64/libgdk-x11-2.0.so.0
#8  0x0000003ea1c46262 in gdk_events_pending () from /usr/lib64/libgdk-x11-2.0.so.0
#9  0x0000003ea1c4662e in gdk_add_client_message_filter () from
/usr/lib64/libgdk-x11-2.0.so.0
#10 0x0000003ea012703a in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#11 0x0000003ea012a1b5 in g_main_context_check () from /usr/lib64/libglib-2.0.so.0
#12 0x0000003ea012a4dd in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#13 0x0000003ea181ed03 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#14 0x00002aaaaf2a9c3a in nsAppShell::Run (this=0x6cf910) at nsAppShell.cpp:139
#15 0x00002aaaaf720738 in nsAppStartup::Run (this=0x6cf890) at nsAppStartup.cpp:150
#16 0x000000000040b4cc in XRE_main (argc=Variable "argc" is not available.
) at nsAppRunner.cpp:2351
#17 0x0000003e9d11ce54 in __libc_start_main () from /lib64/libc.so.6
#18 0x0000000000406b29 in _start ()
#19 0x00007fffff9705b8 in ?? ()
#20 0x0000000000000000 in ?? ()
(gdb) 

This happens to me quite often on both my x86 laptop and x86_64 desktop systems
running Fedora Core 5.  I thought that Firefox uptime might have had something
to do with it, but that doesn't seem to be the case.   Even a freshly started
Firefox is doing it to me today on most pages of my company's intranet.

I don't think the application crashes when you close the bogus window, but the
close handler of that extra window is actually tied to the main Firefox window's
handler which then closes.

There was some discussion about this on fedora-devel-list on May 15th and 16th,
but no one seemed to really know what's causing it.

Duplicate of bug 193548 ?

This looks like upstream bug 349497:
https://bugzilla.mozilla.org/show_bug.cgi?id=349497

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

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

upstream bug mentioned in comment 4 has been closed as DUP of
https://bugzilla.mozilla.org/show_bug.cgi?id=263160 I really believe that
although this bug is bad, we really cannot fix it. Closing as UPSTREAM and
waiting when the fix will come to us.

This is a major crashing problem that Red Hat and Fedora users need to continue
to be aware of.

It is inaccurate to close as UPSTREAM, when upstream has no clue about this
problem either.  "waiting when the fix will come to us" could take forever, and
in the meantime, firefox will continue to crash for a great many users.

For the record, if we were to fix this bug, it would not go into our packages
without serious vetting upstream in CVS HEAD and an analysis of the patch's risk
in the branch.  This has something to do with frame creation and is one of the
most fragile pieces in the upstream codebase.  We are _not_ going to deviate
from upstream here.

This was appropriately closed upstream.  We are looking at fixing the bug
upstream, but it is rather difficult to reproduce reliably in every setup.  I
personally have only had this happen to me twice ever.

Has been happening to me about twice a week for longer than I can remember now
(probably a year at least).  Latest version of everything in FC5.  I do heavy
browsing and never quit the browser, with dozens of windows open most of the
time.  Heavy ebay use seems to hasten the crash.

I realize this happens to other people alot.  I'm not saying it's not important
to fix, but unless I can reproduce on demand, it's pretty damn hard for me to do
anything with it, given it's likely a race in the frames/threading code.  To fix
this we need to figure out why the browser gets itself into an invalid state.  I
invite people to join in the discussion upstream and possibly offer patches.

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

We just updated the Firefox version in Fedora/development from 2.0 to a 3.0
pre-release version, which improves performance, memory usage, and fixes many
bugs and crashes.

Closing as CANTFIX since we aren't fixing bugs filed against 2.0 now that 3.0 is
in.  If this bug is still present in rawhide using a Firefox 3.0 version, please
re-open this bug.

Thanks and Happy Holidays

The upstream bug is not closed, so I don't think this is fixed in Firefox 3.0 at
all.

I haven't seen it in a while, but that is almost certainly due to most
auto-refresh things being adblocked out of existence. Still, opening because of
the upstream bug.

Since going F8 when it came out, this bug hits way less often, but it still
happens every week or so.  In fact, I'm also now seeing weird grey/blank pages
after about a week of browsing w/o quitting.

OK, so we have it confirmed on F8. Have anybody seen it with FF3 on Rawhide?

Since this bugzilla report was filed, we have seriously upgraded Gecko-related
packages in Rawhide, which may have resolved this issue. Users who have
experienced this problem are encouraged to upgrade their system to the latest
version of their distribution available.

Closing this bug as CANTFIX. Please, reopen, if this bug is still reproducable
on the latest update of your distribution.

[This is mass-closing of bugs which seem to be too old and irrelevant anymore;
we are sorry, if we are closing your bug in mistake; please, don't hesitate to
reopen, if it is still alive issue.]

Update to my comment #16: Firefox crashes on me nearly daily (tons of browsing /
refreshes of complicated pages) but I'm now pretty sure it's a different bug as
I can't recall seeing the symptom specific to this bug, which is a new empty
window popping up just before crashing.  So this specific crashing bug may not
apply anymore.

I just put in the very latest Firefox for F8 and we'll see how it goes.