corrupt places.sqlite file leads to 2 problems: (1) persistent hang at exit & (2) 0 byte json/html bookmark backups/exports

NEW
Unassigned

Status

()

P3
normal
5 years ago
a year ago

People

(Reporter: mozillauser2010, Unassigned)

Tracking

26 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

1) initially installed Firefox in about 2010. Set to automatic updates. Firefox was current through version 26. Plug-ins and extensions were also all current.

2) Gradually build up approximately 25,000 bookmarks over that period.

3) 
a) Use Firefox in a real-world manner, with occasional force-closes with Task Manager and Process Explorer, occasional computer power-offs, and similar problems.

b) Unbeknownst to me, file C:\Users\[username]\AppData\Roaming\Mozilla\Firefox\Profiles\4vo5cy1t.default\Places.sqlite, at about 30,720 KB size, becomes corrupted at some point in this period.

4) Continue to use Firefox normally, by browsing webpages like Twitter, Facebook, news sites like CNN and Google News, search engines like Bing and Google, etc.

5) 
a) On occasion, encounter problem after closing Firefox by File menu - Exit or the X in the upper right-hand corner.  At some time after closing Firefox (say, 20 seconds or 20 minutes or 20 hours later), try to start Firefox as usual through its Start Menu icon or Quick Launch icon.  

b) On these occasions, receive error dialog window - "Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system"

c) Be forced to stop Mozilla process by Task Manager or Process Explorer in order to restart Firefox.

6) Problem described in step 5 begins to occur every time Firefox is closed.

7) Troubleshooting by disabling all plug-ins and all extensions does not solve problem.

8) Perform other troubleshooting, but not effective.

9) Attempt to backup bookmarks by Bookmarks menu, Show All Bookmarks. Then Import and Backup, Backup..., then specify Desktop or C:\, and keep default file name. Hit Save.

10) Also attempt to export bookmarks to HTML. Under Import and Backup dropdown menu, Export Bookmarks to HTML, then specify Desktop or C:\, and keep default name of bookmarks.html. Hit Save.

11) At some point 5+ minutes later, view these files through Windows Explorer.  Files are 0 bytes.

12) After reading through advice on Mozillazine and other sources, install Places Maintence 1.3 add-on.  Under plug-in Options menu, "Check Integrity" and "Check Coherence" report no problems.

13) Use Places Maintenance add-on "Rebuild Indices".  Rebuild completes and issues message log.

14) Close Firefox through Process Explorer.  Restart Firefox.  Close Firefox again -- no hang on exit.

15) Repeatedly try closing Firefox.  Each time, Firefox process disappears on its own from Task Manager and Process Explorer after about 1 second.

16)
a) Try Backup and Export of Bookmarks to .json/.html files.  Backup and export now work and produce bookmarks-2013-12-18.json file of 7,868 KB size and bookmarks.html file of 21,552 KB size.

b) Processes of Backup and Export do run slowly, and use 100% CPU utilization according to Process Explorer, and require approx. 5+ minutes to complete. However, they do at least run and that seems to be good enough.


Actual results:

Corrupted places.sqlite meant that I had to kill the Firefox process manually each time to close and restart Firefox and that Backup or Export of my bookmarks led to 0 byte files.

Overall, I had to run the add-on Places Maintenance to rebuild the indices in order to have Firefox work normally again.


Expected results:

Ideally, during Backup or Export attempts, if Firefox encounters a corrupted places.sqlite file, it should alert the user that the backup/export was not completed.

Perhaps Firefox should keep a log of each time it hangs at shutdown and if this happens every time, it should scan Places.sqlite on its own and fix it.

Even more ideally, Firefox should do some sort of regular integrity check/scan on places.sqlite, and if it finds a problem, fix it.

Comment 1

5 years ago
User Agent:  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0

I'm having a similar problem as described above, although the shutdown completes after a few minutes in general. 

I have approx 35,000 bookmarks, and when closing firefox it consumes 100% of CPU for a 4-5 minutes, while writing the bookmarkbackups json file. I believe this became a problem only in FF 26 - I haven't noticed any hangs in earlier versions IIRC.

I've tried fixing this with a fresh install and new profile, into which I imported a bookmark backup. But this did not change the behaviour, it still hangs at least once a day while writing the backup files (which are about 9MB of json data currently)

Comment 2

5 years ago
Created attachment 8359126 [details]
Process analysis from OSX taskmanager

Attached a process analysis from the OSX taskmanager while FF 26 is hanging on shutdown due to bookmark backups.

Comment 3

5 years ago
Just to confirm that this is still a problem in the latest FF27. The workaround using the "Places Maintenance" addon does not fix it in my case.


I also found another bug report, that describes a similar behaviour, and is maybe related: #965695

Comment 4

5 years ago
Oops, actual link for the related issue: https://bugzilla.mozilla.org/show_bug.cgi?id=965695

Comment 5

5 years ago
ref bug 623489
Component: Untriaged → Places
Product: Firefox → Toolkit
(In reply to mozillauser2010 from comment #0)
> Overall, I had to run the add-on Places Maintenance to rebuild the indices
> in order to have Firefox work normally again.

This is interesting, what Places Maintenance does is just invoking some code in Firefox that we usually run once a week, on idle. Do you happen to leave your browser unattended/idle some times, or do you usually browse in small sessions?

> Expected results:
> 
> Ideally, during Backup or Export attempts, if Firefox encounters a corrupted
> places.sqlite file, it should alert the user that the backup/export was not
> completed.

the problem is that we can't detect that kind corruption, that's a data coherency issue, the best thing we can do is try to blindly fix old known issues, that is what Places Maintenance does, and what we try to do once a week on a long idle time.
On the other hand, if we'd instead find a "real" corruptio due to the filesystem handling, then we could do basically nothing without causing some dataloss.

> Perhaps Firefox should keep a log of each time it hangs at shutdown and if
> this happens every time, it should scan Places.sqlite on its own and fix it.

We don't store backups at shutdown anymore starting from Firefox 30. From that version the backup process is also much faster so it may help with your issue. There was a regression in versions 26->30 making the backup process slower.

> Even more ideally, Firefox should do some sort of regular integrity
> check/scan on places.sqlite, and if it finds a problem, fix it.

We already do that, so we should rather find why it was not working for you.
> Bug summary : (2) 0 byte json/html bookmark backups/exports

Was SQLite 3.7.11(released on 2012-03-20) or newer already used in build at 2013-12-18?
If so, new "SQLITE_ABORT and SQLITE_ABORT_ROLLBACK from SQLite 3.7.11" may produce loss of row update, because "SQLITE_ABORT and SQLITE_ABORT_ROLLBACK" is converted to generic NS_ERROR_FAILURE.
No one perhaps retries insert/update/delete upon SQLITE_ABORT, and no one perhaps retries Roolback upon SQLITE_ABORT_ROLLBACK.
See bug 1062823.

SQLITE_ABORT, will perhaps produce "loss of update", unless retry is executed upon generic NS_ERROR_FAILURE by MozStorage code or by caller of MozStorage.

If Rollback is not retried upon SQLITE_ABORT_ROLLBACK, lock of some rows perhaps won't be released forever until restart.
But I don't know it can produce phenomenon like "(1) persistent hang at exit".
FYI.
SQLite 3.7.17 was already used in Fx 24.0 at 2013/09, so spec change by SQLite 3.7.11 may affect on this bug which was reported for Fx 26 on 2013-12-18.
FYI.
If lock of a row is not released due to SQLITE_ABORT_ROLLBACK for Rollback(), SQLITE_BUSY is always returned to subsequent request to the row. If it happens on Rollback(), first issue of Bug 1062823 may occur.
   SQLITE_BUSY is converted to NS_ERROR_STORAGE_BUSY. Because current code is following, infinite loop can occur after SQLite 3.7.11.
   And, .SQLite 3.7.17 was already used in Fx 24.0 at 2013/09, and SQLite 3.8.8.2 is currently used.

   Rollback:
   do {                                     
      rv = mConnection->ExecuteSimpleSQL(   
           NS_LITERAL_CSTRING("ROLLBACK")); 
      if (rv == NS_ERROR_STORAGE_BUSY)      
        (void)PR_Sleep(PR_INTERVAL_NO_WAIT);
   } while (rv == NS_ERROR_STORAGE_BUSY) ;
Following NSPR log with mozStorage:5 was reportd to a forum in Japan.
> 2015-03-06 05:44:35.927000 UTC - 3480[1b7fbef0]: sqlite3_trace on 22ea6d60 for 'INSERT OR REPLACE INTO webappsstore2 (scope, key, value) VALUES ('1.0.0.721.:http:8823', 'skin.gray2x', '{ ... }') '
> 2015-03-06 05:44:35.927000 UTC - 3480[1b7fbef0]: Statement::ExecuteStep error: database is locked
> 2015-03-06 05:44:35.927000 UTC - 3480[1b7fbef0]: sqlite3_trace on 22ea6d60 for 'ROLLBACK'
Because this is localStorage case, call is localStorage.setItem('skin.gray2x', ...).
It looks for me "SQLITE_BUSY to ROLLBACK request".

If possible, get NSPR log with timestamp,mozStorage:5 for this bug, please.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.