Comparing the current UPDATE_STATUS telemetry data week to week, it shows that ~5% of updates fail with error code 1 which is a memory error. Some weeks it shows as much as 8%, other weeks as low as 3%. We currently use memory errors a lot throughout the updater code though, so it's hard to tell what the problem is. We also assume a memory error when the error could be from something else such as in the case of WideCharToMultiByte calls. This bug is to add different error codes and to adjust the telemetry histogram so we can get a better idea why these errors happen. A follow up bug will likely be posted once we gather the needed data from this bug.
Created attachment 588798 [details] [diff] [review] Patch v1.
Attachment #588798 - Flags: review?(robert.bugzilla)
Comment on attachment 588798 [details] [diff] [review] Patch v1. Nice!
Attachment #588798 - Flags: review?(robert.bugzilla) → review+
Pushed to inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/acbca13be1cb
Target Milestone: --- → mozilla12
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
So relating to this telemetry data: We are still showing an error of 1 on telemetry. None of these new codes are being shown. Possibly people can't update and are stuck on an old version always returning a memory error of 1. But I'm a bit confused because these users would have had to update originally to the telemetry build that ehsan did for update.status. Seems like either we're returning an error of 1 on all telemetry updates, or I missed a return code somewhere that is still 1.
I should note that a couple of time I manually put values in my file for testing and those show up, so I don't know what's going on.
Bug 731901 explains Comment 5. This fix is still valid though because it just creates new error codes to help narrow down errors when they happen.
You need to log in before you can comment on or make changes to this bug.