563903 - 100% CPU core usage whilst system is idle, process monitor shows repeated access and file attribute updates to places.sqlite and places.sqlite-journal

Status: RESOLVED WORKSFORME

(Toolkit :: Places, defect)

Description

[Tony]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB6 (.NET CLR 3.5.30729)

Every so often Firefox will ramp up to 100% CPU usage on a single core whilst I'm not even using it. This continues for over 10 minutes. I have used SysInternals (now MS) Process Monitor tool to see if will reveal anything specific system usage by FireFox. What is noticeable is a rapid repetition of events associated with places.sqlite (QueryStandardFileInformation) and places.sqlite-journal (SetAllInformationFile, SetEndOfFileInformation) being the main ones. This continues for as long as FF is using CPU. The last instance resulted in me having to close FF to stop it. I cannot remember it ever resolving itself by leaving FF running. I tried inspecting threads to see whether that revealed anything but I only ever saw the main thread in a running state at "Win32StartAddr:0x00401840" which I doubt means much. 

There were no noticable changes to the contents from a cursory inspection of the places.sqlite or places.sqlite-journal (which remaned at zero bytes). Is this expected periodic behaviour of some sort such as cleaning out old data? My current places.sqlite file is 14MB.

During the time its running with high CPU everything within FF becomes extremely slow to respond to clicks and rendering of pages is very slow.

Are there any debug symbols available for the windows release to enable further debugging when such an incident happens in future?

Reproducible: Couldn't Reproduce

Comment 1

[Tony]

It just happened again and this time I let it run for about 6-7 minutes and it finished by itself. I took a few copies of places.sqlite while the heavy CPU usage was going on and a quick binary compare showed the files contents were being updated. I assume therefore its part of the cleanup/maintenance of the history data. I will do some comparisons of the table contents if i get time to see how much actually changed. 

So this one possibly isn't a bug. The only thing I'm doing at the moment which might be contributing to this is access a page which is doing being refresh using a meta equiv REFRESH in the HTML contents to repeatedly call the same page updating a start offset in the query string, in all its gets called about 70 times (from the first hit till the final refresh which completes the task). I have probably done this twice since starting FF and this problem occuring this time round with at least a 15 minutes gap from the last page hit and FF then consuming 100% cpu.

All during this the places.sqlite-journal file remained at zero bytes.

Comment 2

[Tony]

Having compared the snapshots of the places.sqlite file the only difference after the heavy usage were:

1) a single moz_places entry for the URL "about:plank" was removed
2) 24 rows from moz_annos were removed

All the removed rows from moz_annos appear to have a anno_attribute_id value of 9 which is "google-toolbar/thumbnail".

Comment 3

[Marco Bonardo [:mak]]

see bug 489173

Comment 4

[Marco Bonardo [:mak]]

Do you have latest google toolbar version? that add-on gave us big headaches in the past as you can see.

Comment 5

[Marco Bonardo [:mak]]

also see https://bugzilla.mozilla.org/show_bug.cgi?id=489173#c9

Comment 6

[Tony]

That does not appear to be the same thing necessarily. My places.sqlite is not massive. I have version 6.1.20091119W of the google toolbar add-on. There were only a few rows that were removed and that shouldn't take that long and be that heavy a query to consume so much CPU for such a long period should it?

Comment 7

[Marco Bonardo [:mak]]

So, Places by itself on idle does some work when entering idle, then it stops any action till "back". This in Firefox 4, Previous versions could do small continuous work on idle to sync tables or expire.
So I think what we could do on our side is fixed, if there is some issue due to the Google Toolbar, should be easy to verify by disabling the add-on and comparing the activity.