Closed Bug 1194471 Opened 9 years ago Closed 9 years ago

Deleting a large number of history entries causes Firefox to become unresponsive, triggers "Warning: Unresponsive script"

Categories

(Firefox :: Bookmarks & History, defect)

41 Branch
x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 734643

People

(Reporter: gkommet, Unassigned)

Details

When deleting a large number of History items, Firefox became unresponsive for several minutes, with repeated "Warning: Unresponsive script" messages during the deletion. My total number of history entries was about 31-34,000 prior to the deletion and I deleted about 13-16,000 of the records. This happened on Firefox Developer Edition (Aurora) 41.0a2, Build ID 20150810004008. I may have missed a script name/line or two because I didn't realize the issue was going to be so acute until the 3rd or 4th script warning, but I noted the following: chrome://browser/content/places/tree.xml:47 chrome://browser/content/places/tree.xml:315 chrome://browser/content/places/treeView.js:149 Each of those appeared at least twice, though I'm not sure if that is meaningful or it just happened to be the place Firefox picked to pause for the warnings. During periods between the script warnings, the firefox.exe process was pegging one of my cores at 100%. It was occasionally using up to ~25% of a second core, but mostly seemed to be CPU-bound using a single thread. My assumption is that the work was done in the main Firefox thread, because the browser was completely unresponsive/hung until the next script warning. I wasn't even able to bring a different Firefox window to the top. My hard drive is a Micron C400 256GB SSD (SATA III, random 4k write throughput claimed to be 50,000 IOPS), so I don't think this was a disk speed issue. Then again, my SSD is encrypted via Absolute Secure Drive and I don't know how that would affect CPU usage during a lot of I/O. I'm not confident I can easily reproduce since I don't have a backup of my Places files from before the delete and I'm not sure how to simulate 11 months worth of Google pageviews to recreate my starting conditions. I did do some digging in Bugzilla and found a few potentially/likely related bugs, including 2-3 closed bugs that may be duplicates: Bug 466421: Seems to be exactly the same issue, but was closed 3.5-4 years ago as WFM after the improvements in Bug 681420. Bug 948500: Opened to report that moving a large number of bookmarks, but another commenter mentioned the issue also affecting deleting history records. One comment even mentions the same "chrome://browser/content/places/tree.xml:47" script line I saw. Closed 1.5 years ago as WFM. Bug 1134260: Reports the Library window hanging when deleting large numbers of bookmarks, but I'm unclear whether the entire browser hung or just the Library window. Bug 1140902: Mentions the browser hanging during large deletes. My places.sqlite-wal is currently small (a few KB), but I did not see whether it grew large during the delete process, which leads to... Bug 871908: Might actually be the root cause of my issue, but I don't understand enough about Places to know. My uncertainty is increased by the fact that this bug seems to blame disk I/O when my issue seemed to be CPU-bound. Then again, for all I know my issue was also I/O-based and it just happens that my laptop CPU became the bottleneck (due to encryption, or just a fast SSD).
It's a known issue.
Whiteboard: DUPEME
I did some more digging, and it seems like this is likely just a consequence of Places code running on the main thread. Is that correct, and if so then should I close it as a dupe of Bug 975979 (OMTPlaces), or perhaps more specifically its child Bug 699850 (asyncHistory)?
this is a mixture of various causes, among which there is also off-main-thread Places, but not just that. I think we should dupe to one of the other "removing a bunch of history is slow" bugs.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.