Crash in abort | `anonymous namespace''::wasapi_stream_init

RESOLVED FIXED in Firefox 53

Status

()

defect
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: ehoogeveen, Assigned: padenot)

Tracking

({crash, regression})

Trunk
mozilla53
Unspecified
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr45 unaffected, thunderbird_esr45 unaffected, firefox50 unaffected, firefox51 unaffected, firefox52 unaffected, firefox53 fixed)

Details

(crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

This bug was filed from the Socorro interface and is 
report bp-56036a5b-4843-4d66-b7c0-3151b2170122.
=============================================================

This crash showed up with yesterday's Nightly. When it happens Windows asks me to open it up in a debugger, which points to the assertion at [1] failing. That assertion was added in bug 1331869.

Oddly I don't get a crash report for these crashes, which might bear looking into in its own right. Clearly some people *are* getting crash reports though; I chose a random one to file this bug.

I can trigger this crash consistently from a clean profile by going to YouTube and watching any video. Others have reported hitting it too in [2], so I suspect the problem is widespread.

I have my speaker configuration set to 5.1 in Windows 10, which might be relevant given the failing assertion.

Is this XASSERT meant to be a release assertion? It certainly seems to be according to [3], but I wonder if we should make it MOZ_ASSERT or MOZ_RELEASE_ASSERT instead so it plays nice with the crash reporter.

[1] https://hg.mozilla.org/mozilla-central/file/487a4e43eb9d1f04a5d8e3dd183fe38dbe105e1f/media/libcubeb/src/cubeb_wasapi.cpp#l1793
[2] http://forums.mozillazine.org/viewtopic.php?f=23&t=3026773
[3] https://dxr.mozilla.org/mozilla-central/rev/3cedab21a7e65e6a1c4c2294ecfb5502575a46e3/media/libcubeb/src/cubeb-internal.h#79
Flags: needinfo?(achronop)
Paul can you please take a look?
Flags: needinfo?(achronop) → needinfo?(padenot)
(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #0)
> Oddly I don't get a crash report for these crashes, which might bear looking
> into in its own right.

> Is this XASSERT meant to be a release assertion? It certainly seems to be
> according to [3], but I wonder if we should make it MOZ_ASSERT or
> MOZ_RELEASE_ASSERT instead so it plays nice with the crash reporter.

I filed bug 1332937 about this.
MozReview-Commit-ID: 5UTudDZljKI
Attachment #8829361 - Flags: review?(achronop)
Assignee: nobody → padenot
Status: NEW → ASSIGNED
Attachment #8829361 - Attachment is obsolete: true
Attachment #8829361 - Flags: review?(achronop)
Attachment #8829364 - Flags: review?(achronop) → review+
Pushed by paul@paul.cx:
https://hg.mozilla.org/mozilla-central/rev/36486fdc3813
For mono or stereo in AudioStream.cpp until the rest of the code is multichannel-aware. r=achronop a=tomcat
Pushed directly to central per Tomcat's instructions.
Flags: needinfo?(padenot)
(In reply to Paul Adenot (:padenot) from comment #6)
> Pushed directly to central per Tomcat's instructions.

yeah so it makes also todays nigthly :)
Marking 52 as affected so we don't lose track if/when bug 1331869 gets uplifted there.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Duplicate of this bug: 1332894
I assume the OSX-specific patch that landed in bug 1331869 means that 52 is unaffected here?
Flags: needinfo?(padenot)
Ryan, yes, this is bug is about a different issue.
Flags: needinfo?(padenot)
You need to log in before you can comment on or make changes to this bug.