Closed Bug 1079312 Opened 10 years ago Closed 10 years ago

AsyncShutdownTimeout "AddonManager: Waiting for providers to shut down.", "OpenH264Provider", crash in mozalloc_abort(char const* const) | NS_DebugBreak | nsDebugImpl::Abort(char const*, int)

Categories

(Toolkit :: Add-ons Manager, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox33 --- wontfix
firefox34 + fixed
firefox35 --- fixed
firefox36 --- fixed

People

(Reporter: Irving, Assigned: gfritzsche)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-49345111-dcff-470a-bbad-8ba912141004.
=============================================================

Exception telemetry is showing {"file":"resource://gre/modules/addons/OpenH264Provider.jsm","message":"TypeError: this._log.warning is not a function","line":274,"context":"provider startup","module"

Not sure whether this is causing the shutdown hang or not, but it's close enough to be worth looking at.

(spreadsheet of the recent exception telemetry extract at https://docs.google.com/spreadsheets/d/1s_x8tYo8UDq29peO56kgAV5TbB-Sbw59fN26TbJfDv0/edit?usp=sharing)
This is weird - this should be here:
http://hg.mozilla.org/mozilla-central/annotate/e4cfacb76830/toolkit/mozapps/extensions/internal/OpenH264Provider.jsm#l274
... which doesn't use this._log.warning.

If this is the exception handler 2 lines down, it's still weird - we initialize this._log a few lines earlier.
Are there any known failure scenarios with Log.jsm?
Actually, the this._log.trace() line a little earlier didn't throw, so the logging instance must have broken in the mean-time.
Oh, nevermind - obviously there is a difference between log.warning() and log.warn(). Yikes.
[Tracking Requested - why for this release]:
Bug 1070036 was uplifted to fix an issue on systems where OpenH264 activation failed, but introduced a wrong function name for logging.
Bug 1074561 was supposed to fix the underlying issue, but the report here was after that bug landed, so this is still an issue.

This is after any important initialization of the OpenH264Provider, so still mostly an issue with noise in the addon provider exception telemetry - hence not requesting tracking for 33 and setting wontfix there.
Attached patch FixSplinter Review
Assignee: nobody → georg.fritzsche
Status: NEW → ASSIGNED
Attachment #8502570 - Flags: review?(irving)
Attachment #8502570 - Flags: review?(irving) → review+
Comment on attachment 8502570 [details] [diff] [review]
Fix

Approval Request Comment
[Feature/regressing bug #]: OpenH264 integration.
[User impact if declined]: Noise in the addon provider exception telemetry
[Describe test coverage new/current, TBPL]: No good coverage with reasonable efforts here.
[Risks and why]: Low risk, trivial change / typo-fix.
[String/UUID change made/needed]: None.
Attachment #8502570 - Flags: approval-mozilla-beta?
Attachment #8502570 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/26841ad4d2eb
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Attachment #8502570 - Flags: approval-mozilla-beta?
Attachment #8502570 - Flags: approval-mozilla-beta+
Attachment #8502570 - Flags: approval-mozilla-aurora?
Attachment #8502570 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
(In reply to Georg Fritzsche [:gfritzsche] from comment #4)
> This is after any important initialization of the OpenH264Provider, so still
> mostly an issue with noise in the addon provider exception telemetry - hence
> not requesting tracking for 33 and setting wontfix there.

Setting as qe-verify-.
Flags: qe-verify+ → qe-verify-
You need to log in before you can comment on or make changes to this bug.