Closed Bug 630139 Opened 13 years ago Closed 11 years ago

Firefox doesnt fully exit, even after you tell it to

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: joduinn, Unassigned)

Details

(Whiteboard: [softblocker])

Attachments

(7 files)

screenshot of dock
73.53 KB, image/png
Details
Another shark profile
1.22 MB, application/octet-stream
Details
screenshot from top
48.87 KB, image/png
Details
shark profile while existing Minefield 2011-02-16
1.61 MB, application/octet-stream
Details
shark profile while exiting Minefield 2011-02-18
368.76 KB, application/octet-stream
Details
screenshot of "top" while running nightly 2011-02-18
120.55 KB, image/png
Details
4.0rc1 crash stack during force-quit
190.79 KB, text/plain
Details 
Using FF4.0beta10 on OSX10.6.6.

1) Start Firefox, and load some pages/tabs.
2) Leave Firefox running for several hours
3) Do "Firefox->Quit".
4) Watch all windows (slowly!) close
5) Notice that after the last window closes, the dock still has an active "lit dot" beside the Firefox icon. This remains even hours later. The only way to remove this is by doing OS-level Force-Quit.


Note: To reproduce this, you have to have Firefox running for a long time (> hours). If you start Firefox, and then quickly quit Firefox within a few minutes, Firefox works normally and fully exits as expected.
Attached image screenshot of dock — 
1) this screenshot was taken a few hours after doing Firefox->Quit, and leaving the computer idle for those hours.
2) note all firefox windows closed soon after doing Firefox->Quit. This dot beside Firefox icon remained for hours, until I finally did Force-Quit.
Is is reproducible in Safe Mode (to rule out any misbehaving add-on) ?
Can you get a Shark profile of what's happening when you try to quit?
Keywords: qawanted
(In reply to comment #2)
> Is is reproducible in Safe Mode (to rule out any misbehaving add-on) ?

Yes. Started FF4.0b10 in Safe Mode late yesterday afternoon, left machine running with usual set of tabs+windows while I went out for class+dinner, and then was unable to exit Firefox when I got home.
Please renominate once there's a profile from Shark that we can use to tell us where to look.
blocking2.0: ? → -
New info: was able to reproduce this on a friends mac running 10.6. Happy, I think, that its not just my machine. FYI: She has only a handful of tabs in 6-8 windows, and was able to reproduce this by leaving Firefox running for a full business day and then not being able to exit Firefox when she was stopping work. 


(In reply to comment #5)
> Please renominate once there's a profile from Shark that we can use to tell us
> where to look.
Happy to - can you point me to docs on how to do this?
blocking2.0: - → ?
I've told you we need a Shark profile before we can block. I'll get someone to go see you and help you get a sample.
blocking2.0: ? → -
> (In reply to comment #5)
> > Please renominate once there's a profile from Shark that we can use to tell us
> > where to look.
> Happy to - can you point me to docs on how to do this?

(In reply to comment #7)
> I've told you we need a Shark profile before we can block. I'll get someone to
> go see you and help you get a sample.

Cool. Who will that be? Again, if there's docs I can follow, please point me to them instead.


Also, fyi, I can still reproduce this problem using 4.0beta11 on osx10.6.
blocking2.0: - → ?
From offline emails, I *think* this is the shark profile info being asked for. Let me know if not. The file is too big to post to bugzilla, so I've placed it on people, in /home/joduinn/Shark_profile_exiting_ff40beta11.mshark.zip. Happy to provide any other info if it helps.

This shark profile was taken after firefox told to exit, after all firefox windows closed, and while firefox icon on dock remained active.

Several minutes later, I eventually did ForceQuit on Firefox, as I have to do every time I try to exit Firefox after running Firefox for multiple hours.
Attached file Another shark profile — 
I've been running Firefox for hours. Tried to quit. All windows closed, until left with just the Firefox icon-with-active-dot on dock. After a few minutes of this, I ran Shark.

This shark profile is configured differently to the previous one I posted, I think I'm now using Shark correctly, but let me know if I'm not doing this right.
Reproduced on multiple machines, has shark data -> Blocking for investigation.

Damon, can you ask the person in MV best suited for analyzing shark dumps to walk over to John's desk and take a look?
blocking2.0: ? → final+
Whiteboard: [hardblocker]
--> Core::NSS

From a quick inspection of the Shark data, looks like we're spending an awful lot of time stuck in libnspr4.dylib -- sdwilsh mentioned that there's a known deadlock there that we've had for a long time, also affects Thunderbird, apparently?

adding bsmith

joduinn: can you please try to head up to engineering and show someone this bug?
Component: General → Security: PSM
Product: Firefox → Core
QA Contact: general → psm
The deadlock in NSS was probably bug 588698 which was fixed in the version of NSS that we shipped a few betas ago. I don't see anything NSS-related in the shark profile. The shark profile shows that 50% of the sampled time is spent waiting on conditional variables under XRE_AddStaticComponent, the cycle collector, and the Javascript garbage collector.
Component: Security: PSM → XPCOM
QA Contact: psm → xpcom
The shark profile here doesn't have enough symbols to actually make head or tails of it. We're probably in a thread deadlock, but we can't see up the stack enough to tell. The XRE_AddStaticComponent thing, for example, is just the only exported symbol we can see: we're obviously not in that code at shutdown.

I thought we had in-product symbols for nightlies but not betas, but a debug nightly would probably be best. Ted, do you remember?

I'm not going to hardblock on something which isn't widely reported via input.mozilla.org.
Component: XPCOM → General
QA Contact: xpcom → general
Whiteboard: [hardblocker] → [softblocker]
We don't strip our nightly builds, but we do strip our release builds. You can get symbols for the betas using the fetch-symbols.py script:
http://hg.mozilla.org/users/jwatt_jwatt.org/fetch-symbols

but I'm not sure if Shark does the right thing here.
Nightlies are built without frame pointers, so shark can't get useful stacks.

We really need to bring back the --enable-shark builds (now that it works again).  Or do we still do those?
In this case at least the debug builds are perfect.
(In reply to comment #15)
> We don't strip our nightly builds, but we do strip our release builds. You can
> get symbols for the betas using the fetch-symbols.py script:
> http://hg.mozilla.org/users/jwatt_jwatt.org/fetch-symbols
> 
> but I'm not sure if Shark does the right thing here.

Thanks ted. 

sayre asked me to try running latest minefield for a day, see if that fixes it. I'm now trying 4.0b12pre(2011-02-16). If this repros the problem and gives more useful data, great. Otherwise, I'll go back to beta11 and try the fetch-symbols suggestion.
Attached image screenshot from top — 
I note this screenshot was taken *after* firefox/minefield had closed all windows, and while waiting for the rest of firefox/minefield to exit (which, as always, never happened).
(In reply to comment #18)
> sayre asked me to try running latest minefield for a day, see if that fixes it.
> I'm now trying 4.0b12pre(2011-02-16). If this repros the problem and gives more
> useful data, great. 

Running 2011-02-16 fails the same way as beta11. If you leave firefox/minefield running for a few hours, and then quit:
a) it takes a long time to close all windows
b) after all windows closed, the Firefox/Minefield process will never exit, and requires you to force-quit it. 
c) I note that the memory usage is huge, looks like a leak someplace.
shark profile taken while hung-on-exit of nightly build 2011-02-16.
After leaving the machine idle for a few hours, top shows Firfox using >3gb ram. 

A memory leak in Firefox?

This explains the really-slow performance of the machine, which causes me to want to exit Firefox, and hit the "hang on exit".
(In reply to comment #23)
> After leaving the machine idle for a few hours, top shows Firfox using >3gb
> ram. 
> 
> A memory leak in Firefox?
While possible, memory usage is also going to depend on browser usage.  How many tabs in all windows do you have open?  I seem to recall you having lots in the past, but your habits may have changed.
Started Minefield 2011-02-19 and left running unattended for 4 hours; happened again. firefox-bin using >2gb ram. Needed force-quit.

I've got 39 windows open, with a combined total of 103 tabs. Most are one-tab-per-window. One outlier window had 14 tabs.
I had three machines running overnight with a similar state as reported and in all three machines the memory footprint I could see in their system monitors remained pretty constant. All used the latest nightly.

The linux machine had about 300 windows, at least two of which had 10 tabs, all with bugzilla content. That used up to 1.5gb of memory, but it never went past that. It took minutes to quit. The machine has 2gb total memory.

The Mac OS X 10.6.6 machine had about 100 windows, with several windows having more than 10 tabs. The memory hovered around 750mb. It took about a minute to quit. This machine has about 2gb total memory.

The Win7 machine had about 80 windows open, with several windows with about 5-10 tabs. Here Fx used about 500mb of memory, and it took about a minute or less to quit. This machine only has 1gb of total memory.

Anecdotally, I used to experience this problem a few months ago, for about a week or so, then I changed profiles and the problem went away. I'll talk to the guys working on a soak testing environment and see if we can try this on a few different types of Macs, and see what we find.
juanb: thanks for the experiment. 


This is still happening for me in beta12. Same symptoms. :-(
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
This is still consistently happening in rc1. Managed to get crash while doing ForceQuit - see attached.
The Firefox Incomplete Quit
February 16, 2012

Currently using Firefox 10.0.1 on Mac running Mac OS 10.6.8 Snow Leopard.  Have been watching this phenomenon for about 6 months, having had the same trouble with versions of Firefox, back to I can't remember when last year (2011).

A quick Firefox session, as described above by John O'Duinn - get on the Internet, do a few things, and then Quit, works.  You can Quit successfully, either using the Quit command for the Firefox icon in the Dock, or using the Quit command under the File menu.

Anything longer then a "quick Firefox session," and then trying to Quit, particularly by use of a right-click on the Firefox icon in the Dock, will *NOT* cause a complete and successful Quit *most of the time.*

What does happen, *after doing that,* is that, if you wait a while, and then just click *once* on the same Firefox icon in the Dock, there is a very brief flash, or glimpse, of a Firefox window, showing its frame but otherwise the window within the frame is all black ... and then "poof!" just like that, that temporary Firefox window is gone, and then, the tiny "lit triangle" in the Dock, showing that somehow Firefox *had, til then, been running* ... FINALLY is gone, too, and the application's processes seem to be completely Quit.

If, instead of trying to Quit via the Dock, you use the Quit command under the File menu, the odds of The Incomplete Quit happening, are less, but it still can happen.

Using the Mac Terminal application and bash commands kill or killall DO NOT WORK - meaning, they will not force a Quit.

Leaving, if you intend to force the matter, these 3 chances:

1) That last click on the Firefox icon
   in the Dock, which results in the
   glimpse of a Firefox window, then
   all ist kaput.

2) Force Quit under the Apple menu.

3) Using the Activity Monitor.
Re my "2012-02-16 20:59:46 PST" comments, above ...

The problem also happens with SeaMonkey 2.7.1.

I suspect that the trouble has something to do with the Dock.
Works for me using Latest Nightly 27 on Mac OS 10.7.5
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: