dead Add-ons Manager bug finally hit me

RESOLVED DUPLICATE of bug 671894

Status

()

Toolkit
Add-ons Manager
--
major
RESOLVED DUPLICATE of bug 671894
6 years ago
6 years ago

People

(Reporter: Dave Garrett, Unassigned)

Tracking

13 Branch
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

6 years ago
Created attachment 634531 [details]
extensions.log

+++ This bug was initially created as a clone of Bug #713280 +++

See bug 674344 for my prior abstract attempt to delve into this.

I now have first-hand knowledge; the Firefox profile on my desktop computer hit the Add-on Manager killer bug. Flagfox notices and whines while everything else just looks dead. The Add-on Manager shows no installed extensions, but does still show the plugins and the one light-weight theme installed (but not the default theme). Bug 713280 comment 11 is spot-on as a work-around. The affected profile only has 7 extensions installed, even less than what I normally use on my laptop.

Now, the odd thing is that when I installed Firefox 13 on this computer I loaded up the profile, it showed the addon compatibility checker window, then loaded fine. That was yesterday; today I start it up and it dies.

Flagfox did get an update pushed out on Friday, but according to my Firefox profile backup done immediately prior to installing Firefox 13, the Flagfox 4.1.16 monthly update had already been installed and was in use. No other extensions updated recently.

Note that this wasn't a normal auto-update. That computer just had Firefox 11 on it and I don't have auto-updating on there. This was just an extraction of a .tar.bz2 from mozilla.org into a new dir in /opt leaving the old install there and changing the OS shortcut to the new path. Whenever I actually get around to updating the OS on that thing I'll probably just use Ubuntu's package but it's a little stupid right now. (on my laptop I use Aurora)

This profile is fairly old and I've updated the thing many many times before without incident.

UA: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0.1
OS: Kubuntu 10.04 32-bit (running on a 64-bit CPU)

Installed extensions (all enabled):

Adblock Plus 2.0.3
Adblock Plus Pop-up Addon 0.3
Browse By Name 1.1
Copy Link Name 1.3.2
Flagfox 4.1.16
Flashblock 1.5.15.1
Quick Search Bar 3.0.13

The only two lines in extensions.log dated this year:

2012-06-18 21:41:23 ERROR addons.xpi: Failed to open database (1st attempt): [Exception... "Component returned failure code: 0x80630001 (NS_ERROR_STORAGE_BUSY) [mozIStorageService.openUnsharedDatabase]"  nsresult: "0x80630001 (NS_ERROR_STORAGE_BUSY)"  location: "JS frame :: resource:///modules/XPIProvider.jsm :: XPIDB_openDatabaseFile :: line 4229"  data: no] at resource:///modules/XPIProvider.jsm:4229
2012-06-18 21:41:23 ERROR addons.xpi: Error processing file changes: TypeError: this.installLocations is null at resource:///modules/XPIProvider.jsm:1788

The backup just prior to the installing of Firefox 13 was done at 2012-06-18 21:35:45. The backup was done from a little script and only includes files with data needing backup (i.e. cache, safe browsing data, etc.), however it does have the old extensions.ini and extensions.sqlite. Trying to load up the profile with just this just gives me what I saw last night: nothing broken. I'll attach both the old and new here for completeness.

If someone can divine some insight as to what died in Toolkit to make this so, please oh please help.
(Reporter)

Updated

6 years ago
Priority: P1 → --
(Reporter)

Comment 1

6 years ago
Created attachment 634532 [details]
extensions.sqlite (broken)

This is the db from the broken profile.
(Reporter)

Comment 2

6 years ago
Created attachment 634535 [details]
extensions.ini

This is the ini from the broken profile.
(Reporter)

Comment 3

6 years ago
Comment on attachment 634535 [details]
extensions.ini

The only difference in this file from the old one in the backup is that the Extension0 path now points to the firefox 13 dir instead of 11.
Attachment #634535 - Attachment description: extensions.ini (broken) → extensions.ini
(Reporter)

Comment 4

6 years ago
Created attachment 634536 [details]
extensions.sqlite (backup)

This is the db from the profile just prior to installing the new Firefox version.
(Reporter)

Comment 5

6 years ago
Created attachment 634538 [details]
about:support

This is everything from about:support. The only differences in this from broken to after deleting and regenerating extensions.sqlite is that the extensions show in the list again.
(Reporter)

Comment 6

6 years ago
> The backup was done from a little script and only includes files
> with data needing backup (i.e. cache, safe browsing data, etc.)

Typo: data needing backup (i.e. _no_ cache, safe browsing data, etc.)
(Reporter)

Comment 7

6 years ago
Something in the build system somewhere must cut out all the MPL boilerplate, as it's not in the released XPIProvider.jsm file, thus borking up the line numbers when I want look up the file online. The two errors in extensions.log are in the following locations:


2012-06-18 21:41:23 ERROR addons.xpi: Failed to open database (1st attempt): [Exception... "Component returned failure code: 0x80630001 (NS_ERROR_STORAGE_BUSY) [mozIStorageService.openUnsharedDatabase]"  nsresult: "0x80630001 (NS_ERROR_STORAGE_BUSY)"  location: "JS frame :: resource:///modules/XPIProvider.jsm :: XPIDB_openDatabaseFile :: line 4229"  data: no] at resource:///modules/XPIProvider.jsm:4229

http://hg.mozilla.org/releases/mozilla-release/file/f48d675ffa9f/toolkit/mozapps/extensions/XPIProvider.jsm#l4251


2012-06-18 21:41:23 ERROR addons.xpi: Error processing file changes: TypeError: this.installLocations is null at resource:///modules/XPIProvider.jsm:1788

http://hg.mozilla.org/releases/mozilla-release/file/f48d675ffa9f/toolkit/mozapps/extensions/XPIProvider.jsm#l1814


1) Why is it reporting it's busy in the first errror?
2) What does it mean that this.installLocations is null?
3) Can the second error be fixed with some error checking?
4) Did this.rollbackTransaction() silently fail after the second error?
5) Did this leave something broken in the database?

http://hg.mozilla.org/releases/mozilla-release/file/f48d675ffa9f/toolkit/mozapps/extensions/XPIProvider.jsm#l4353

Tony's extensions.log in attachment 535195 [details] also has the same two errors, however they happened well over a month prior to this issue happening. Is it maybe possible that this is the actual breakage, but it doesn't become apparent until much later for some odd reason?
(Reporter)

Comment 8

6 years ago
I'm lucky that I have a before and after for the extensions.sqlite, so I decided to try and see what's different. I just installed a program to browse the two sqlite files to compare them (as a diff obviously went nowhere). In the working one "SELECT id FROM addon" correctly returns 8 rows and in the broken one it returns 0 rows. ... and that's where I'm lost, as I know hardly anything about SQL databases.
Attachment #634532 - Attachment mime type: text/plain → application/octet-stream
Attachment #634536 - Attachment mime type: text/plain → application/octet-stream
The errors in comment 7 look like bug 671894 (see also bug 572322 for extra background info). IIRC, the second error always occurs after getting NS_ERROR_STORAGE_BUSY.

As for the broken database... it's not corrupt (passes the SQLite integrity check), the schema is fine, but the tables have no data in them. When we detect a corrupt database, or have to upgrade/downgrade the schema, we delete the database file and re-create it - presumably that's what has happened here (whether it be due to the previous app update or not), but the data hasn't been re-inserted (possibly due to the above errors).
Depends on: 671894

Comment 10

6 years ago
This happened to me the other day too. *sigh*

I think what happened in my case is that just as Firefox was restarting after updating an add-on, I accidentally closed it while it was still loading.

I tried to reproduce it, but couldn't.
(Reporter)

Comment 11

6 years ago
Would the patch in bug 671894 detect this state and regenerate the data? If not, it really needs to be able to check for this and recover, even if the cause gets fixed elsewhere.
(In reply to Dave Garrett from comment #11)
> Would the patch in bug 671894 detect this state and regenerate the data? If
> not, it really needs to be able to check for this and recover, even if the
> cause gets fixed elsewhere.

I'm pretty sure (but not 100%) it should prevent getting into that state. Though IIRC it won't recover from an empty database. I'm not sure what we can do to detect that, but bumping the schema version will automatically regenerate the data (which we can do in bug 671894).
Calling this a dupe of bug 671894, which just landed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 671894
You need to log in before you can comment on or make changes to this bug.