1323252 - Crash in InvalidArrayIndex_CRASH | nsTArray_Impl<T>::operator[] | mozilla::a11y::AccessibleWrap::GetRemoteIAccessibleFor

Status: RESOLVED INCOMPLETE

(Core :: Disability Access APIs, defect)

Description

[Andrew McCreight [:mccr8]]

This bug was filed from the Socorro interface and is 
report bp-b850280f-4a39-44e6-97f1-49ea12161211.
=============================================================

I came across this crash on crash stats. There aren't a ton of these, maybe a few dozen, but the only explanation I can think of for why we're hitting an array bounds error here is that somehow we're changing the length of the array while we're iterating over it, which could be bad.

Comment 1

[Andrew McCreight [:mccr8]]

This loop is iterating using indices, so I think the array access here can't go too wrong, but maybe something bad could happen otherwise.

Comment 2

[Nathan Froyd [:froydnj]]

Presumably fixing the loop to test against Length() every time would fix this...but not sure what's removing DocAccessibleParent*s from the loop.

Comment 3

[Trevor Saunders (:tbsaunde)]

I think what's going on here is that while the main thread of the parent process is blocked on a proxied COM call a child process sends the parent process a message that removes one of the documents from the array.  I'm not sure the main process can get kicked out of blocking to do that, but maybe?  Then if one of the COM calls fails we will increment the counter and continue the loop possibly hitting this crash.

It seems to me once sIDGen.IsSameContentProcess() has returned true there's no point in looking at any remote docs other than the current one, so further failures in the loop might as well be handled with break, or by just pulling all that stuff out of the loop.

Comment 4

[Andrew McCreight [:mccr8]]

I'm just going to mark this incomplete. I see one crash on 54 in the last week. Feel free to reopen if you come up with anything.