1274902 - Crash in `anonymous namespace''::get_output_buffer

Status: RESOLVED WONTFIX

(Core :: Audio/Video: cubeb, defect, P2)

Description

[Nicholas Nethercote [inactive]]

This bug was filed from the Socorro interface and is 
report bp-bd9b2c6a-e94e-48fb-b515-b8eef2160516.
=============================================================

I see 5 of these in the past 7 days, 4 on 49 and 1 on 48. It's a null-deref, presumably stm or stm->output_client is null.

kinetik, can you please investigate?

Comment 1

[Maire Reavy [:mreavy]]

Paul -- Can you take a look at this?  I think this may be in the code you landed (and I believe Matthew is busy).  Thanks.

Comment 2

[Paul Adenot (:padenot)]

`stm` is not null, because `XASSERT` is a release assert, and checks
`stm->output_stream_params.rate != 0`, and this went fine.

It must be that `stm->output_client` is null. This is only nulled in
`close_wasapi_stream`.

`close_wasapi_stream` is called in a variety of location:
- When reconfiguring a stream, we close and re-setup the stream. This occurs on
the same thread as this crash.  If the reconfigure fails, the thread exits, so
it cannot crash there.
- When destroying a stream. This is preceded by a call to
`stop_and_join_render_thread`. This lets the rendering thread exits properly. It
can fail sometimes for unknown reason, and so we've put in a time limit for the
join operation, but only on Nightly for now, and this has one occurence on
Aurora.
- When starting a stream, and the device has been invalidated, we close the
stream and set up a new one with a (possibly) new default device. This can only
happen if the stream has not been started previously, or has been stopped, which
means that the thread is not running.

I'm not sure what to do here. I'm going to put in a couple more asserts and see
if we're crashing on those, maybe higher up, to get some sense of what is
happening here.

Comment 3

[Paul Adenot (:padenot)]

Also this is a bit weird, this started to happen in a period of time where we haven't landed anything.

Comment 4

[Nicholas Nethercote [inactive]]

(In reply to Paul Adenot (:padenot) from comment #2)
> `stm` is not null, because `XASSERT` is a release assert, and checks
> `stm->output_stream_params.rate != 0`, and this went fine.
> 
> It must be that `stm->output_client` is null.

Just to confirm this, I looked at the minidump. It says that `stm` was non-null. It didn't have enough data to say what value `stm->output_client` had.

Comment 5

[Paul Adenot (:padenot)]

https://github.com/kinetiknz/cubeb/pull/109

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature '`anonymous namespace''::get_output_buffer':
 - nightly (version 50): 0 crashes from 2016-06-06.
 - aurora  (version 49): 2 crashes from 2016-06-07.
 - beta    (version 48): 490 crashes from 2016-06-06.
 - release (version 47): 0 crashes from 2016-05-31.
 - esr     (version 45): 0 crashes from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       0       0       0       2       0
 - beta         68      68      69      55      78      68      55
 - release       0       0       0       0       0       0       0
 - esr           0       0       0       0       0       0       0

Affected platform: Windows

Comment 7

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.