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.
would be great if someone could load this db, see if the problem is reproduceable. if so, we should handle this error.
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.
taking a look at the db
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
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.
Created attachment 342235 [details] [diff] [review] patch
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 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?
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).
(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.
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
not going to make 3.1 since we still ignore causes
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.
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.
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
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