Closed
Bug 474699
Opened 16 years ago
Closed 10 years ago
Sometimes the shutdown of Firefox takes ages while consuming 100% cpu load
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: marcia, Unassigned)
Details
(Keywords: hang, perf)
Attachments
(3 files, 1 obsolete file)
I have now seen this twice using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090121 Shiretoko/3.1b3pre.
STR:
1. Have a bunch of tabs open.
2. The pref for "Always Clear my Private Data" is on
3. When I get asked to save my tabs I select "Quit"
The browser does not shut down cleanly, and I have to envoke Force-Quit.
I have seen the bug manifest itself on two separate macs. Nothing comes up in the Mac console.
Comment 1•16 years ago
|
||
Does it happen every time, or just intermittently? Have you see this on trunk (and possibly other platforms as well)?
Reporter | ||
Comment 2•16 years ago
|
||
Seems to happen just intermittently, and noticed it when I was trying to shut down in different ways while clearing data. I will keep on eye out, but I have not noticed it in on the trunk but that may be because lately I am running more on 1.9.1.
Comment 3•16 years ago
|
||
Marcia, I've seen such a behavior with 1.9.1 too. It has taken about 2 minutes to shut down Firefox. I haven't killed the process. So please wait the next time and have a look if it exits automatically.
Comment 4•16 years ago
|
||
I don't think that this hang is special to the clearing private data feature. Personally I don't have this option checked for shutdown.
I saw this kind of thing some minutes ago. Shiretoko was getting really slow and I wasn't able to work at all. Each action behaves like an old snail and sometimes the beach ball comes up. The activity monitor shows me about 60% cpu load for Shiretoko and a memory usage about 650MB. Further 35 threads were open.
I wanted to restart Shiretoko but the shutdown takes about 15 minutes. Within this time Shiretoko consumes 100% cpu load all the time. The number of threads dropped to 13 within a minute but then no other thread was stopped for the rest of the time. I wanted to run Shark on the Shiretoko process but the application closes itself within some seconds. So the only thing I can provide is the process analysis of the activity monitor. Further I have a list of open files. Both things I'll attach now. I hope that helps to figure out what's going on here.
Severity: normal → critical
Keywords: hang
Summary: Shiretoko does not always shut down cleanly when exiting → Sometimes the shutdown of Firefox takes ages while consuming 100% cpu load
Comment 5•16 years ago
|
||
Comment 6•16 years ago
|
||
Comment 7•16 years ago
|
||
I had the same situation again just a couple of minutes ago. I hardly believe that this hang happens while using the sleep mode (hibernation) regularly. As often you put your MacBook into this state as more memory Firefox seems to use and probably some threads get locked up?
Flags: blocking-firefox3.1?
Comment 8•16 years ago
|
||
This shouldn't block until/unless we find a way to reliably reproduce it.
Henrik? :-)
Comment 9•16 years ago
|
||
I agree with smichaud; this feels a little flaky right now to block, though decidedly problematic. Perhaps related to bug 470274?
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Comment 10•16 years ago
|
||
Steven, I'm using Firefox on my daily basis. I don't do strange things. Just doing my work on Bugzilla, using Socorro, Gmail and so on. It doesn't happen all the time but while having it open for a couple of days sometimes (oh yeah i forget to update) Firefox gets slower and slower and consumes a lot of memory. I still believe that this happens due to the hibernation mode.
Marcia, how many extensions you have installed? Probably we should cross-check if one of those could also be the reason. The problem is still that I cannot deactivate them in my normal profile. Probably I have to make a copy and run both in parallel. Mmh. It's kinda hard to get STR here. :/
Reporter | ||
Comment 11•16 years ago
|
||
I tend to see this issue intermittently. When I do see it I usually have lots of tabs open (more than 50+ in three different windows). My 1.9.1 profile has only the WOT (Web of Trust) extenstion and my trunk profile has no extensions installed. When it happens I end up having to force quit the browser since it seems as if it will not shut down cleanly.
Comment 12•16 years ago
|
||
Mmh ok.
Steven, it looks like that the attached process analysis don't help you? Would a measured shark session be more useful?
Comment 13•16 years ago
|
||
> Steven, it looks like that the attached process analysis don't help
> you?
It's interesting that all the activity on the main thread is in
JavaScript code or system library code. There are also a couple of
calls to spin_lock (one on the main thread and one on "Thread_2903"),
which might show thread contention. This doesn't tell me much ... but
others might be able to read more into it.
> Would a measured shark session be more useful?
I think that's highly unlikely. But post one if you'd like.
Comment 14•16 years ago
|
||
One thing that might help:
Post a few more samples, preferably taken during different instances
of the hang/slowdown. Patterns might emerge from comparison between
them.
Of course you'll need to test with debug builds (or opt builds with
debug symbols) -- not with packaged distros (like downloaded
nightlies).
Comment 15•16 years ago
|
||
> It's interesting that all the activity on the main thread is in
> JavaScript code or system library code.
Argh. That's because you've been testing with packaged distros (like
nightlies), and your Mozilla-specific symbols are almost all spurious.
Try to reproduce the hang/slowdown with a debug build, and post the
sample(s) here.
Comment 16•16 years ago
|
||
Mak or Dietrich, could this somehow be related to bug 407981? I don't really think so but just to make sure we can exclude this.
Comment 17•16 years ago
|
||
can't tell off-hand, there are not enough infos to exclude anything.
Comment 18•16 years ago
|
||
I haven't had this problem since the name switch to 3.5b4pre.
Comment 19•15 years ago
|
||
(In reply to comment #18)
> I haven't had this problem since the name switch to 3.5b4pre.
Marcia, do you say "ditto" to the above/still seeing the problem?
Keywords: perf
Comment 20•15 years ago
|
||
I'm still seeing slow exits with 3.6.3. I suspect it is places cleanup, which I believe will be limited to short runs at exit in a future release.
Reporter | ||
Comment 21•13 years ago
|
||
I rarely run 3.6.x these days, so I cannot really say reliably whether I would still see this or not.
(In reply to Wayne Mery (:wsmwk) from comment #19)
> (In reply to comment #18)
> > I haven't had this problem since the name switch to 3.5b4pre.
>
> Marcia, do you say "ditto" to the above/still seeing the problem?
Comment 22•13 years ago
|
||
I'm still experiencing those issues with Aurora builds like the one I have currently installed: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a2) Gecko/20111011 Firefox/9.0a2 ID:20111011042016
Comment 23•13 years ago
|
||
I can reproduce this every time I use Firefox for a prolonged time. Using Aurora currently.
Comment 24•13 years ago
|
||
Comment 25•13 years ago
|
||
Sorry, this time it's the correct one.
Attachment #588968 -
Attachment is obsolete: true
Comment 26•12 years ago
|
||
In the latest nightely, for me, it does not consume a lot of CPU any more, but it takes 5 minutes (easily) up to 15 minutes to shut down properly.
Depends mostly on how long was firefox opened.
Even by then I try to restart it once per 2 days.
I don't restart it a lot because it takes 15 mins to properly start (but that's a different issue)
Comment 27•12 years ago
|
||
Bruno, could you have a look at the profiler extension? With it you can profile shutdown and startup times. It might reveal which code is responsible for such a long shutdown. The extension you can grab here:
https://github.com/bgirard/Gecko-Profiler-Addon/blob/master/geckoprofiler.xpi
More information and how to use it is located on its AMO page:
https://addons.mozilla.org/en-us/firefox/addon/gecko-profiler/
Steps you would have to do:
1. When you want to restart Firefox, click its icon in the toolbar and select Firefox Restart
2. When Firefox is back, click the Analyze button
3. If you see a graph with a lot of red background, you should upload the profile and share it with us, or save locally and send it to me via email.
Thanks.
Comment 28•12 years ago
|
||
I don't know how but that extension crashes my OS with a blue screen with:
SYSTEM_SERVICE_EXCEPTION
I tried both versions. The one on github and the one of mozilla addons website. Both crash with the same error.
I'm using the latest stable firefox build.
I'm using win6.1 x64
Comment 29•12 years ago
|
||
(In reply to brunoaiss from comment #28)
> I don't know how but that extension crashes my OS with a blue screen with:
> SYSTEM_SERVICE_EXCEPTION
>
> I tried both versions. The one on github and the one of mozilla addons
> website. Both crash with the same error.
> I'm using the latest stable firefox build.
> I'm using win6.1 x64
Wow, that should never happen. Can you please file a new bug for this crash in Core:Profiler? Please put me on the CC list for further investigation of the crash. We may have to wait until we can make more progress here.
Comment 30•10 years ago
|
||
Do you have an profilable testcase that isn't already covered by the bugs blocking bug 819063? (
note some bugs cover Firefox running a long time or using lots of memory - which may be atopal's case
Flags: needinfo?(hskupin)
Flags: needinfo?(a.topal)
Comment 31•10 years ago
|
||
This is a very old bug, so I doubt that the hangs I see during shutdown nowadays is the same as reported here years ago. Not sure if we can do any action here.
Flags: needinfo?(hskupin)
Comment 32•10 years ago
|
||
I don't have this issue anymore, but I also have changed profiles a dozen times since this report.
Flags: needinfo?(a.topal)
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•