371398 - 100% CPU usage on "clear private data" prompt (gettimeofday in strace)

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Arthur]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070223 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070223 Minefield/3.0a3pre

 

Reproducible: Always

Steps to Reproduce:
1. Enable "Alway clear my private data when I close Minefield" under Edit/Preferences/Privacy/Private Data
2. Enable "Ask me before cleaning private data" as well
3. Quit Browser

Actual Results:  
-> Upon the "clear private data" screen, the browser uses 100% of the CPU.


Running a "strace -f" yields endlessly those same lines:

[pid 18840] poll([{fd=3, events=POLLIN}, {fd=12, events=POLLIN}, {fd=16, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=19, events=POLLIN|POLLPRI}, {fd=20, events=POLLIN|POLLPRI}, {fd=8, events=POLLIN}], 7, 0) = 0
[pid 18840] gettimeofday({1172252754, 383202}, NULL) = 0
[pid 18840] ioctl(3, FIONREAD, [0])     = 0

The gettimeofday makes me wonder whether it's related to bug 273310 and bug 303231.

Comment 1

[Arthur]

Hm, I didn't want to open this bug as NEW. Can't reset to UNCONFIRMED, adding qawanted keyword instead because I need help in triaging this.

Comment 2

[Arthur]

This still occurs with current nightlies. Interestingly the CPU doesn't spike when the "clear private data" window comes up after a crash on restarting the browser. It's only when closing it.

Bug 86632 also describes a busy looping situation with 0 ms polling.

Comment 3

[Rolf Leggewie]

How long does it remain at 100%?  If FF has something to do, wouldn't you expect 100% usage of the CPU?  I fail to see the problem here.

Comment 4

[Arthur]

It's a busy loop. CPU usage stays forever at 100% until you dismiss the dialog. Because of the similar stack traces it might be that the other bugs I've referenced above enter the same busy loop in a less easily reproducable way. This one here always results in a busy loop.

Comment 5

[Sylvain Pasche]

WFM with Gecko/2007091704 Minefield/3.0a8pre

Can you reproduce with a clean profile and no extensions?

Comment 6

[Arthur]

Yes, on all nightlies since I've filed the bug. Just tried today with a new nightly. What platform are you on? Mind, it's not a hang but a busy loop which sucks your laptop battery empty in no time.

Comment 7

[Sylvain Pasche]

Sorry, I was not applying the steps correctly (I thought it was consuming CPU after clicking the "Clear Private Data", but it does when displaying the dialog).

Now I'm able to reproduce the issue.

Comment 8

[Arthur]

Conforming also on Win XP with 2007091705. Instead of changing the setting under Edit/Preferences/Privacy/Private Data you have to use Tools/Options/Privacy/Private Data.

Comment 9

[Sylvain Pasche]

After all the browser windows are closed, nsBaseAppShell::Exit() is called which sets nsBaseAppShell::mExiting to PR_TRUE.
In this situation, the event processing does not block any more:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp&rev=1.7&cvsroot=/cvsroot&mark=241-244#241
This makes the CPU usage reach 100% while the sanitize dialog is open.

Commenting those two lines solves the issue on Linux at least. I guess they are necessary in some situation or other platforms?

Otherwise, one other workaround would be to wait for XPCOM shutdown before entering this "mayWait = PR_FALSE" state.

CCing Darin for ideas.

Comment 10

[Sylvain Pasche]

Attachment: Delays "mayWait = PR_FALSE" until XPCOM shutdown

Comment 11

[Arthur]

Has this been fixed by another checkin? I can't see it anymore with Minefield 2008022404.

Comment 12

[Stephen Donner [:stephend] Not actively reading bugmail]

Yes; bug 404531...

Comment 13

[Arthur]

Resolving as fixed. 
Fixed with the following checkin for bug 404531:
/cvsroot/mozilla/browser/components/nsBrowserGlue.js,v  <--  nsBrowserGlue.js
new revision: 1.55; previous revision: 1.54

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4pre) Gecko/2008022404 Minefield/3.0b4pre

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022404 Minefield/3.0b4pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008022404 Minefield/3.0b4pre