667386 - history menu hangs UI for 30+ minutes, hogs cpu after syncing

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[Leho Kraav (:macmaN @lkraav)]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

After setting up a fresh profile for FF5 and syncing against my Weave Minimal Server with "Replace all data on this computer with sync server data" option, clicking History menu hangs UI and hogs CPU for an extremely long period of time (30+ minutes). I'm keeping 180 days of history in my browsers.

Tested the same operation now with 4.0.1. It is showing History menu without any glitches during and after sync.

My last experience with UI freezes similar to this was when I drag'n'dropped about 2000 bookmarks from one folder to another in Bookmark Manager. This apparently resulted in a total UI freeze for several hours while SQLite operations were taken care of. This feels quite similar and process sample shows SQLite activity happening.

Hints welcome on how to provide some more and/or detailed information.

Attaching process sample.

Reproducible: Always

Comment 1

[Leho Kraav (:macmaN @lkraav)]

Attachment: firefox-5.0-history-hang.txt

Comment 2

[Leho Kraav (:macmaN @lkraav)]

Attachment: firefox-5.0-history-hangreport.txt - force quit hangreport, seems to be formatted a bit differently

Comment 3

[Marco Bonardo [:mak]]

(In reply to comment #0)
> I'm keeping 180 days of history in my
> browsers.

This doesn't matter, Firefox 4 and later don't care about days.

> My last experience with UI freezes similar to this was when I drag'n'dropped
> about 2000 bookmarks from one folder to another in Bookmark Manager.


This is completely unrelated to this bug, that bug was due to real (useless) work done, while here you have a thread-locking issue.

The call to sqlite3_enable_shared_cache() in your stack makes me think this has nothing to do with history at all, Places doesn't use shared cache at all in any of its connections.

Were you doing anything other interesting in the browser? Some special page open (maybe using indexedDB)? which other data was being synced, cookies and passwords?

Comment 4

[Leho Kraav (:macmaN @lkraav)]

Thanks for explaining about the issue. No, I am not doing *anything* in the browser.

 1. Set up new profile
 2. Set up sync, wait for some time for it to complete
 3. Click History = insta-hang UI

I could make a screencast of this, or show you over VNC (that'd be more flexible for more tries too, set it up over IRC).

I'm thinking it might actually hang instantly as soon as it starts the sync process.. or after a certain data amount has been reached, I haven't tested that yet.

Comment 5

[beingalink]

Attachment: Protocoll of the event

I'm having exactly the same issue on my Macbook using OS X 10.7.1. Also happens in safe mode. Clicking the History menu makes the browser and the Dock freeze and go heavy on the cpu. Protocoll attached.

Comment 6

[beingalink]

Problem seems to be gone with current nightly.

Comment 7

[Tim (fmdeveloper)]

Leho -> Can you still reproduce with Firefox 9.0.1 or the latest nightly (http://nightly.mozilla.org/)?

Comment 8

[Leho Kraav (:macmaN @lkraav)]

my os x box is currently out of commission, it might take a while to achieve testing capability. aside from that, i have not encountered this issue in my workflows for the past 6 months..

Comment 9

[Tim (fmdeveloper)]

OK - Will close the report for now and post back if you experience again.