Closed Bug 1281402 Opened 3 years ago Closed 3 years ago

Crash in `anonymous namespace''::close_wasapi_stream

Categories

(Core :: Audio/Video: cubeb, defect, P1, critical)

49 Branch
Unspecified
Windows 7
defect

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox47 --- affected
firefox49 --- affected
firefox50 + fixed

People

(Reporter: marcia, Assigned: padenot)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

[Tracking Requested - why for this release]: New crash in nightly.

This bug was filed from the Socorro interface and is 
report bp-68816a27-5524-4ace-814d-ae1602160621.
=============================================================

seen while looking at crash stats. http://bit.ly/28MRaAt.

Frame 	Module 	Signature 	Source
0 	xul.dll 	`anonymous namespace'::close_wasapi_stream 	media/libcubeb/src/cubeb_wasapi.cpp:1733
1 	xul.dll 	`anonymous namespace'::wasapi_stream_render_loop 	media/libcubeb/src/cubeb_wasapi.cpp:880
2 	ucrtbase.dll 	crt_at_quick_exit 	
3 	kernel32.dll 	BaseThreadInitThunk 	
4 	ntdll.dll 	RtlUserThreadStart

ni on kinetik and paul since they worked in that area.
Flags: needinfo?(padenot)
Flags: needinfo?(kinetik)
This pull in you mac fix and the assert fix that I pushed directly to cubeb master, being a simple change.

The issue here is that it's legal to have a thread when calling `close_wasapi_stream`, since, as the stack shows, we're reconfiguring the stream itself. Also we have a shutdown event as well.
Flags: needinfo?(padenot)
Flags: needinfo?(kinetik)
Rank: 15
Priority: -- → P1
Assignee: nobody → padenot
Tracking 50+ for this new crash.
Comment on attachment 8764243 [details]
Bug 1281402 - Uplift cubeb to revision 9a1d6ccd2.

https://reviewboard.mozilla.org/r/60250/#review57132
Attachment #8764243 - Flags: review?(kinetik) → review+
Pushed by paul@paul.cx:
https://hg.mozilla.org/integration/mozilla-inbound/rev/161db04bbc17
Uplift cubeb to revision 9a1d6ccd2. r=kinetik
https://hg.mozilla.org/mozilla-central/rev/161db04bbc17
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
We're still seeing this crash in recent nightlies, after the fix landed (albeit with lower volume, e.g. [1]). Is this expected?

[1] https://crash-stats.mozilla.com/signature/?build_id=20160628030238&product=Firefox&release_channel=nightly&platform=Windows&signature=%60anonymous%20namespace%27%27%3A%3Aclose_wasapi_stream&date=%3E%3D2016-06-28
Flags: needinfo?(padenot)
Yeah it's kind of a different one, we're tracking it in bug 1282464 (the signature is different, but it's the same underlying issue).
Flags: needinfo?(padenot)
Per https://github.com/kinetiknz/cubeb/pull/119, if we're allowing multiple cubeb_stream_stop, then it follows that a second call to close_wasapi_stream will encounter null output_client and input_client, so it looks like we need to remove the assert added in 520761064631ecf9dc2b20a476cc4025953e9804.
See Also: → 1286457
Depends on: 1285541
Crash volume for signature '`anonymous namespace''::close_wasapi_stream':
 - nightly (version 50): 1467 crashes from 2016-06-06.
 - aurora  (version 49): 1 crash from 2016-06-07.
 - beta    (version 48): 0 crash from 2016-06-06.
 - release (version 47): 5 crashes from 2016-05-31.
 - esr     (version 45): 0 crash from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly        155        180        161        176        743          0          0
 - aurora           0          1          0          0          0          0          0
 - beta             0          0          0          0          0          0          0
 - release          0          0          1          1          2          1          0
 - esr              0          0          0          0          0          0          0

Affected platform: Windows
Flags: needinfo?(padenot)
You need to log in before you can comment on or make changes to this bug.