If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Crash in mozilla::a11y::DocAccessible::DoInitialUpdate

Assigned to



Disability Access APIs
13 days ago
a day ago


(Reporter: davidb, Assigned: aklotz)


({crash, leave-open})

Windows 7
crash, leave-open

Firefox Tracking Flags

(firefox57? affected, firefox58 affected)


(Whiteboard: aes+, crash signature)


(1 attachment)

Spun off bug 1383501

This bug was filed from the Socorro interface and is 
report bp-d66274d1-87e3-4728-9de3-a57aa0170913.

We need a way for caller(s) to react smartly when DoInitialUpdate fails. Likely need to be able to return an error code.

Alex this is pretty urgent. Please find AKlotz for high bandwidth details.

Comment 1

13 days ago
I know nothing about this code, and not sure what is a scope of this bug. Aaron probably has more data on it per hg history. Unassigning myself until we have something actionable here.
Assignee: surkov.alexander → nobody
Flags: needinfo?(dbolter)
Flags: needinfo?(aklotz)
Please talk to Aaron for context (we're in meeting now).
Flags: needinfo?(dbolter) → needinfo?(surkov.alexander)
status-firefox57: --- → affected
Priority: -- → P1

Comment 3

11 days ago
I'm still not sure if there's anything we could/should do. We definitely could make DoInitialUpdate to return an error code or throw an exception of whatever, but not sure how it can be used.

Aaron, if you've got ideas on it, please put them here. Otherwise should we wontfix this bug?
Flags: needinfo?(surkov.alexander)
I think at the very least we need to leave it open while I investigate the failure that triggers the assertion.
Flags: needinfo?(aklotz)

Comment 5

11 days ago
(In reply to Aaron Klotz [:aklotz] (a11y work receiving priority right now, please send interceptor reviews to dmajor or handyman) from comment #4)
> I think at the very least we need to leave it open while I investigate the
> failure that triggers the assertion.

right, I thought the bug was about DoInitialUpdate change only.
Assignee: nobody → aklotz
Keywords: leave-open
Created attachment 8909970 [details] [diff] [review]
Add diagnostic asserts
Attachment #8909970 - Flags: review?(jmathies)


6 days ago
Attachment #8909970 - Flags: review?(jmathies) → review+
Bug 1399557: Add diagnostic asserts to interceptor creation code; r=jimm
Bug 1399557: Follow-up: Add check for expected error code; r=bustage

Comment 9

5 days ago
There are 25 crashes from 3 installations in nightly 57-58 starting with buildid 20170921100141 with signature 'mozilla::mscom::Interceptor::GetInitialInterceptorForIID'.
The moz crash reason is always MOZ_RELEASE_ASSERT((((HRESULT)(hr)) >= 0)).
The crashy line is 'ENSURE_HR_SUCCEEDED(hr);'.
Crash Signature: [@ mozilla::a11y::DocAccessible::DoInitialUpdate] → [@ mozilla::a11y::DocAccessible::DoInitialUpdate] [@ mozilla::mscom::Interceptor::GetInitialInterceptorForIID]
[Tracking Requested - why for this release]:
There are 1622 crashes for 57 installations in 57.0b0 (dev edition) with signature 'mozilla::a11y::DocAccessible::DoInitialUpdate'
tracking-firefox57: --- → ?
Showing up as #8 on 58. The installations numbers are really low though.

status-firefox58: --- → affected
There's a mixture of a11y clients in here, about 50%/50% oop/in-proc.
You need to log in before you can comment on or make changes to this bug.