Last Comment Bug 452193 - Places Library window is empty due to corrupt places.sqlite (invalid left pane root)
: Places Library window is empty due to corrupt places.sqlite (invalid left pan...
Status: VERIFIED FIXED
: verified1.9.1
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Firefox 3.6a1
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 444290 (view as bug list)
Depends on: 431558 466422 484019
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-26 00:40 PDT by Arie Paap [:wildmyron]
Modified: 2009-11-26 06:59 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
corrupt places.sqlite (172.00 KB, application/octet-stream)
2008-08-26 00:40 PDT, Arie Paap [:wildmyron]
no flags Details
patch (1.21 KB, patch)
2008-10-08 06:55 PDT, Marco Bonardo [::mak] (Away 6-20 Aug)
no flags Details | Diff | Splinter Review
patch (1.28 KB, patch)
2008-10-08 12:45 PDT, Marco Bonardo [::mak] (Away 6-20 Aug)
dietrich: review+
Details | Diff | Splinter Review

Description Arie Paap [:wildmyron] 2008-08-26 00:40:06 PDT
Created attachment 335494 [details]
corrupt places.sqlite

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080825031951 Minefield/3.1a2pre

With the attached places.sqlite the places Library window is blank. When I try to open the library I get the following error:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsINavBookmarksService.removeFolder]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://browser/content/places/utils.js :: anonymous :: line 1123"  data: no]

If I click anywhere in the window I get (3 times):

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: chrome://browser/content/places/tree.xml :: get_view :: line 35"  data: no]

It's not clear to me if this is the same bug as some other places.sqlite corruption bugs such as bug 404171 or bug 445565 because there are different circumstances. Perhaps these bugs will all be fixed by bug 431558 but I've filed a new bug in case the specific corruption is interesting.

Other information:
This places.sqlite comes from a profile I occasionally use for testing. It was created with a pre-places version of Firefox and has been probably been used with various alphas, betas and nightlies of Firefox along the way. I haven't manually edited the file as in bug 404171.

I have no idea how the file came to be corrupt, though I've probably crashed Firefox a few times with this profile.
Comment 1 Dietrich Ayala (:dietrich) 2008-09-10 17:53:24 PDT
would be great if someone could load this db, see if the problem is reproduceable. if so, we should handle this error.
Comment 2 Tracy Walker [:tracy] 2008-09-11 11:47:15 PDT
with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre

I was able to reproduce the empty content Library (the chrome is there) and the error message.
Comment 3 Marco Bonardo [::mak] (Away 6-20 Aug) 2008-09-12 08:57:24 PDT
taking a look at the db
Comment 4 Marco Bonardo [::mak] (Away 6-20 Aug) 2008-09-12 09:12:08 PDT
first look: "all bookmarks" is set to a child of latest headlines that has a missing parent :\ all children of latest headlines have a missing parent...

i'll see if we can detect and come out from such a situation, but i can't see how you can come there... apart with old drag and drop bugs that were throwing roots around... indeed i see that toolbar and unfiled has been re-created
Comment 5 Marco Bonardo [::mak] (Away 6-20 Aug) 2008-10-08 06:53:40 PDT
for this specific case, and for sanity, we should use removeItem instead of removeFolder and still invalidate if it fails.
Preventive maintainance in bug 431558 should take care of fixing orphans and eventually root titles. Titles are missing in this db, so after this fix you will see roots as "(no title)" in the library, but at least the user should be able to export his bookmarks.

As for the reason this did happen, i'm not sure, it's quite messed up, could have been one of the first fsync test builds (with the id corruption bug) or a crash or an alpha migration task. Finding the reason is not trivial.
Comment 6 Marco Bonardo [::mak] (Away 6-20 Aug) 2008-10-08 06:55:06 PDT
Created attachment 342235 [details] [diff] [review]
patch
Comment 7 Marco Bonardo [::mak] (Away 6-20 Aug) 2008-10-08 12:45:03 PDT
Created attachment 342296 [details] [diff] [review]
patch

so, this still contains the try catch.
actually removeItem throws because the item we point to is orphan, so when removeItem tries to read the grandParent itemId it throws.
So 2 cases where it could throw here:
- orphan anno (they are removed in expireAnnotationsParanoid)
- orphan item

without the try catch you get the throws, the item is still removed, so if you close the library and reopen it everything works, while with try catch we don't throw and the library is correct at first opening.
Still try catch could potentially hide other possible throws, but in this case when something goes wrong i think we should still continue and create a new left pane folder.
Comment 8 Dietrich Ayala (:dietrich) 2008-10-09 14:03:18 PDT
Comment on attachment 342296 [details] [diff] [review]
patch

hrm, ok this is fine for wallpaper, r=me. but the root cause of the corruption is not addressed.

if it's that the user tried one of the early fsync builds as you said, then maybe that corruption cause is gone. is there anything in the db that can prove that?
Comment 9 Arie Paap [:wildmyron] 2008-10-09 19:58:32 PDT
Thanks for your time to look into this.

(In reply to comment #8)
> if it's that the user tried one of the early fsync builds as you said, then
> maybe that corruption cause is gone. is there anything in the db that can prove
> that?

I still fave a copy of the profile where I found this bug. If there are other files which might provide clues I am happy to attach them (or even the whole profile).
Comment 10 Marco Bonardo [::mak] (Away 6-20 Aug) 2008-10-13 03:45:58 PDT
(In reply to comment #8)
> if it's that the user tried one of the early fsync builds as you said, then
> maybe that corruption cause is gone. is there anything in the db that can prove
> that?

mh no, instead there is something that proof the opposite, visit triggers are still there, fsync patches should have remove them... i'm waiting before pushing this since i don't have new ideas about the possible cause of corruption for now.

Here we have 2 corruptions:
- children of a folder (feed actually) without their parent
- left pane folder points to one of them

the only interesting thing i see in the db is that 2 roots (toolbar and unfiled) has been redefined and point to greater ids (so instead of being classic ids 4,5 are 18, 19) and all items between 4 and 17 are missing... i suppose this is somehow connected to the corruption.
Comment 11 Marco Bonardo [::mak] (Away 6-20 Aug) 2008-12-11 08:39:42 PST
*** Bug 444290 has been marked as a duplicate of this bug. ***
Comment 12 Alpv 2009-01-11 15:06:37 PST
A similar error happened to me on my Fedora 10 laptop, however the message identified "nsPlacesTransactionsService.js" and the method insertBookmark. The solution was to delete my profile and restart firefox.

-Andrés
Comment 13 Marco Bonardo [::mak] (Away 6-20 Aug) 2009-01-12 12:44:17 PST
not going to make 3.1 since we still ignore causes
Comment 14 Marco Bonardo [::mak] (Away 6-20 Aug) 2009-05-26 03:17:54 PDT
unassigning, not actively working on this and i've not seen other reports about this. also that code has been touched in other bugs. could be WFM actually.
Comment 15 Marco Bonardo [::mak] (Away 6-20 Aug) 2009-05-26 05:30:27 PDT
marking fixed per preventive maintenance bug 431558 and further improvements to the way we manage the left pane folder (bug 466422 and bug 484019).

There are probably many situations where a bad db could cause us issues, but most of the causes for bad dbs come from alpha stage and are less likely to repeat.
Comment 16 Henrik Skupin (:whimboo) 2009-05-26 05:58:55 PDT
Verified fixed by running the following command against the broken places.sqlite file attached as testcase to this bug. And yeah, this is also fixed on 1.9.1.

Components.utils.import("resource://gre/modules/PlacesDBUtils.jsm");
PlacesDBUtils.maintenanceOnIdle();

Tested with builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090525 Minefield/3.6a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre
Comment 17 Gervase Markham [:gerv] 2009-11-26 06:59:34 PST
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Note You need to log in before you can comment on or make changes to this bug.