Closed Bug 853223 Opened 11 years ago Closed 6 years ago

NS_ERROR_FILE_NOT_FOUND in PluginWrapper.installDate

Categories

(Toolkit :: Add-ons Manager, defect, P4)

defect

Tracking

()

RESOLVED INACTIVE

People

(Reporter: gps, Unassigned)

Details

(Whiteboard: [measurement:client])

Attachments

(1 file)

FHR is seeing the following exception when collecting add-on info. It looks like accessing PluginWrapper.installDate is throwing due to a missing file.

https://developer.mozilla.org/en-US/docs/Addons/Add-on_Manager/Addon doesn't say anything about this property possibly throwing. What's the API here? Whose bug is this?

Also, stack traces on errors FTW!

 [updateChannel#nightly,os#WINNT,distributionVersion#,vendor#Mozilla,locale#en-US,appBuildID#20130320031103
,version#22.0a1,distributionID#,id#{ec8030f7-c20a-464f-9b0e-13a3a9e97384},platformBuildID#20130320031103,platformVersion#22.0a1,hotfixVersion#,name#Firefox,xpcomabi#x86-msvc,_v#2

{(Provider error: org.mozilla.addons: Failed to collect: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFile.lastModifiedTime] Stack trace: resource://gre/modules/PluginProvider.jsm:376 < resource://gre/modules/HealthReport.jsm:5930 < onAllAddons()@resource://gre/modules/HealthReport.jsm:5862 < safeCall()@resource://gre/modules/AddonManager.jsm:81 < getAddonsByTypes_noMoreObjects()@resource://gre/modules/AddonManager.jsm:1777 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:176 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < resource://gre/modules/SocialService.jsm:770 < callProvider()@resource://gre/modules/AddonManager.jsm:107 < getAddonsByTypes_nextObject()@resource://gre/modules/AddonManager.jsm:1770 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:182 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < PL_getAddonsByTypes()@resource://gre/modules/PluginProvider.jsm:149 < callProvider()@resource://gre/modules/AddonManager.jsm:107 < getAddonsByTypes_nextObject()@resource://gre/modules/AddonManager.jsm:1770 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:182 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < LightweightThemeManager_getAddonsByTypes()@resource://gre/modules/LightweightThemeManager.jsm:386 < callProvider()@resource://gre/modules/AddonManager.jsm:107 < getAddonsByTypes_nextObject()@resource://gre/modules/AddonManager.jsm:1770 < AOC_callNext()@resource://gre/modules/AddonManager.jsm:182 < getAddonsByTypes_concatAddons()@resource://gre/modules/AddonManager.jsm:1772 < getAddonsByTypes_getVisibleAddons()@resource://gre/modules/XPIProvider.jsm:3283 < AsyncAddonListCallback_handleCompletion()@resource://gre/modules/XPIProvider.jsm -> resource://gre/modules/XPIProviderUtils.js:173 < <file:unknown>)}
This accounts for roughly half of FHR's client-reported errors. While the incidence rate of errors is low (~0.001%), I'd like to address this bug just to cut down on the noise.
What versions of Firefox? This should have been fixed by bug 554780
Today's Nightly.
The header says this was the Nightly built on 20130320031103 (that's this morning's).
17.7% of the beta channel payloads with errors are reporting this error.
Blocks: 846836
(In reply to Gregory Szorc [:gps] from comment #0)
> FHR is seeing the following exception when collecting add-on info. It looks
> like accessing PluginWrapper.installDate is throwing due to a missing file.
> 
> https://developer.mozilla.org/en-US/docs/Addons/Add-on_Manager/Addon doesn't
> say anything about this property possibly throwing. What's the API here?
> Whose bug is this?

It's an Add-ons Manager bug - it shouldn't ever throw. Wallpaper fix coming up with will also include better logging - since we don't know why this is happening, and it generally needs to protect against throwing anyway.
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
FHR reports errors with stack traces. If you stuff an Error away where FHR can find it or surface it via whatever FHR calls, we can get it in Nightly payloads and you should be able to pin down the issue with more certainty.
Attached patch Patch v1Splinter Review
Attachment #736671 - Flags: review?(dtownsend+bugmail)
(In reply to Gregory Szorc [:gps] from comment #7)
> FHR reports errors with stack traces. If you stuff an Error away where FHR
> can find it or surface it via whatever FHR calls, we can get it in Nightly
> payloads and you should be able to pin down the issue with more certainty.

Yea, was pondering the same... filed bug 861078.
Comment on attachment 736671 [details] [diff] [review]
Patch v1

Review of attachment 736671 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/mozapps/extensions/test/xpcshell/test_plugin_installDate.js
@@ +65,5 @@
> +  AddonManager.getAddonsByTypes(["plugin"], function(addons) {
> +    do_check_true(addons.length > 0);
> +    for (let addon of addons) {
> +      try {
> +        addon.installDate;

Check this returns null.
Attachment #736671 - Flags: review?(dtownsend+bugmail) → review+
We now have over 100,000 instances of this error.
needs prioritization
Assignee: bmcbride → nobody
Status: ASSIGNED → NEW
Priority: -- → P4
Whiteboard: [fhr] → [measurement:client]
No longer blocks: 846836, 861078
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: