739682 - Assertion failure: target while installing extension into apps extension directory

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Bob Clary [:bc] (inactive)]

Attachment: crash report

1. Unzip extension into a path
2. Create a file in Firefox's extension directory with name identical to the uuid of the extension which contains the path where you unzipped the extension
3. Start firefox with the -silent command line argument (not sure if this is requiree)
4. Assertion failure: target, at c:/work/mozilla/builds/nightly/mozilla/storage/src/mozStorageAsyncStatementExecution.cpp:224

Seen on Linux and Windows but I don't think Mac yet. Seen in automation but haven't tried to reproduce locally yet. This is common but does not appear to be 100% reproducible each time. First appeared in 2012-03-25 or there abouts.

See bug 721582 where this assertion was introduced.

I'll try to repro locally and give exact steps to reproduce then.

Comment 1

[Bob Clary [:bc] (inactive)]

I haven't been able to reproduce locally perhaps due to the async nature.

Comment 2

[Shawn Wilsher :sdwilsh]

add-ons manager code

Comment 3

[Bob Clary [:bc] (inactive)]

I can reproduce locally on Mac.

/work/mozilla/builds/nightly/mozilla/firefox-debug/dist/FirefoxDebug.app/Contents/MacOS/firefox -CreateProfile "testprofile /tmp/testprofile"
mkdir -p /tmp/sisyphus/extensions/spider
pushd /tmp/sisyphus/extensions/spider/
unzip -d `pwd` /work/mozilla/builds/hg.mozilla.org/sisyphus/xpi/all/spider.xpi 
cd /work/mozilla/builds/nightly/mozilla/firefox-debug/dist/FirefoxDebug.app/Contents/MacOS/extensions
echo /tmp/sisyphus/extensions/spider/ > {47b978aa-2fbb-4f64-886f-b2845d76c709}
cd ..
./firefox -P testprofile -silent

Assertion failure: target, at /work/mozilla/builds/nightly/mozilla/storage/src/mozStorageAsyncStatementExecution.cpp:224

Repeating ./firefox -P testprofile -silent does not repeat the assertion. It appears that calling ./firefox -P testprofile -silent prior to the extension installation makes the assertion go away.

Comment 4

[Mats Palmgren (inactive)]

FWIW, I've seen this assertion a couple of times on Try while running reftests:
https://tbpl.mozilla.org/php/getParsedLog.php?id=11710315&tree=Try&full=1
https://tbpl.mozilla.org/php/getParsedLog.php?id=11712113&tree=Try&full=1

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

*sigh* My world for a useful JS stack.

What kind of scenarios can cause this?

Comment 6

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.