1338025 - Crash in mozilla::BaseAutoLock<T>::BaseAutoLock<T>

Status: NEW

(Core :: Graphics, defect, P3)

Description

[Ting-Yu Chou [:ting] (away)]

This bug was filed from the Socorro interface and is 
report bp-235dd273-57e7-4c19-9161-dd8372170207.
=============================================================
Top #13 of Nightly 20170205030206 on Windows, 49 crashes from 40 installations. Not seeing anyone in 53, the first observation of 54 is from 20170129030205.

The reason is EXCEPTION_ACCESS_VIOLATION_READ and two addresses take the most: 0x17 (88%), and 0x57 (7%).

The stack from 0x17 does not expose specific module, but 0x57 has mozilla::layers::CompositableClient::~CompositableClient.

Comment 1

[Ting-Yu Chou [:ting] (away)]

(In reply to Ting-Yu Chou [:ting] from comment #0)
> The stack from 0x17 does not expose specific module, but 0x57 has
> mozilla::layers::CompositableClient::~CompositableClient.

There's a similar crash in ~CompositableClient on Mac, with address 0x67, see bp-ee1371de-63c1-4be5-b22a-d21ec2170208.

I'll categorize this to graphics for now.

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

Add signatures matching the 0x17 case for Linux and Mac on recent nightlies. I wonder if bp-af510208-d6a9-4b8e-972d-109772170207 is also related.

Comment 3

[Vincent Liu[:vliu]]

The link in [1] is more closer to approach the crash point for ~CompositableClient case. The last frame stoped at mozilla::layers::TextureClientRecycleAllocator::Destroy() and might be in [2].

[1]: https://crash-stats.mozilla.com/report/index/6e79c7da-131f-47e3-915b-5d3212170209
[2]: https://dxr.mozilla.org/mozilla-central/source/gfx/layers/client/TextureClientRecycleAllocator.cpp#249

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

Add another signature for this (Windows 10). CC JW Wang in case he is able to offer insight into the MozPromise callstacks. I believe the CompositibleClient crashes are unrelated however I cannot rule it out given the signatures appeared in the same time frame. Failing to lock a mutex will be a common null/bad pointer failure because that is the first thing we often do (e.g. lock the mutex).

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

In MozPromise::ThenValueBase::DoResolveOrRejectInternal, result is 0 and p is -1. Since p is non-zero, if passes the else, and the offset is +0x18 to the mutex which makes it seem like it is a null pointer (in reality, 0xffffffffffffffff).

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Andrew Osmond [:aosmond] from comment #5)
> In MozPromise::ThenValueBase::DoResolveOrRejectInternal, result is 0 and p
> is -1. Since p is non-zero, if passes the else, and the offset is +0x18 to
> the mutex which makes it seem like it is a null pointer (in reality,
> 0xffffffffffffffff).

http://searchfox.org/mozilla-central/rev/d3307f19d5dac31d7d36fc206b00b686de82eee4/xpcom/threads/MozPromise.h#409
The value of |p| comes from |mCompletionPromise| which can't be -1 unless there is some memory corruption.

Comment 7

[Ting-Yu Chou [:ting] (away)]

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Crash_reporting/Understanding_crash_reports:

Note that due to the way addressing works on x86-64, if the crash address is 0x0 for a Linux/OS X crash report, or 0xffffffffffffffff for a Windows crash report, it's highly likely that the value is incorrect. (There is a bug report open for this problem.) You can sanity-check these crashes by looking at the raw dump or minidump in the Raw Dump tab (see below).

Comment 8

[Wayne Mery (:wsmwk)]

Mostly gone after 52.x, i.e. super rare for any current versions - a few dozen in the past three months https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Alayers%3A%3ACompositorD3D11%3A%3ABeginFrame

Comment 9

[Timothy Nikkel (:tnikkel)]

Very rare crash signatures now. Decreasing severity -> S3.