Bug 193274 - firefox renders page element in its own window; when closed, exits
firefox renders page element in its own window; when closed, exits
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: Christopher Aillon
FF3RawhideClose
: Reopened
: 182171 193548 216098 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-26 14:44 EDT by D. Hugh Redelmeier
Modified: 2008-02-16 09:24 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-08 11:17:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 263160 None None None Never

  None (edit)
Description D. Hugh Redelmeier 2006-05-26 14:44:04 EDT
Description of problem:
After long use, Firefox gets slow and renders some page elements in their own
window.  At that point, closing the unexpectred window (usually? always?) causes
Firefox to exit.

Version-Release number of selected component (if applicable):
firefox-1.5.0.3-1.1.fc5 (x86_64)

How reproducible:
Not very.  Requires up to a week of use before it gets into this state.  Has
happened to me about a half dozen times.


Additional info:
Just now, Firefox got into this state on my machine.  I installed the -debuginfo
and ran gdb against the process before I closed the unexpected window.  It turns
out that Firefox did not crash, it exited!
  (gdb) cont
  Continuing.

  Program exited with code 01.
  (gdb) where
  No stack.
  (gdb) 

On irc.mozilla.org #firefox channel, it was suggested that I include the
TalkBack ID, but TalkBack does not seem to be included in the Fedora-supplied
Firefox.

I would welcome suggestions for finding more details to report.
Comment 1 D. Hugh Redelmeier 2006-05-28 23:01:25 EDT
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) 

Comment 2 Oskari Saarenmaa 2006-06-26 07:51:43 EDT
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.
Comment 3 Trevor Cordes 2006-07-10 16:54:48 EDT
Duplicate of bug 193548 ?
Comment 4 Oskari Saarenmaa 2006-09-16 11:28:57 EDT
This looks like upstream bug 349497:
https://bugzilla.mozilla.org/show_bug.cgi?id=349497
Comment 5 Matěj Cepl 2007-05-26 11:15:59 EDT
*** Bug 216098 has been marked as a duplicate of this bug. ***
Comment 6 Matěj Cepl 2007-05-26 11:16:44 EDT
*** Bug 193548 has been marked as a duplicate of this bug. ***
Comment 7 Matěj Cepl 2007-05-26 11:18:51 EDT
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.
Comment 8 Jeff Garzik 2007-05-26 17:57:39 EDT
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.
Comment 9 Christopher Aillon 2007-05-28 14:04:34 EDT
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.
Comment 10 Trevor Cordes 2007-05-28 15:59:20 EDT
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.
Comment 11 Christopher Aillon 2007-05-28 20:04:57 EDT
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.
Comment 12 Tomas Mraz 2007-08-07 17:08:43 EDT
*** Bug 182171 has been marked as a duplicate of this bug. ***
Comment 13 Matěj Cepl 2007-12-20 11:46:41 EST
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
Comment 14 Tomas Mraz 2007-12-21 02:58:55 EST
The upstream bug is not closed, so I don't think this is fixed in Firefox 3.0 at
all.
Comment 15 Bill Nottingham 2007-12-21 11:12:02 EST
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.
Comment 16 Trevor Cordes 2007-12-24 09:09:42 EST
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.
Comment 17 Matěj Cepl 2008-01-02 10:55:02 EST
OK, so we have it confirmed on F8. Have anybody seen it with FF3 on Rawhide?
Comment 18 Matěj Cepl 2008-02-08 11:17:30 EST
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.]
Comment 19 Trevor Cordes 2008-02-16 09:24:51 EST
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.

Note You need to log in before you can comment on or make changes to this bug.