Closed Bug 1840343 Opened 1 year ago Closed 1 year ago

Crash in [@ mozilla::a11y::RemoteAccessibleBase<T>::DoFuzzyHittesting]

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED FIXED
116 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 --- unaffected
firefox114 --- unaffected
firefox115 --- unaffected
firefox116 --- fixed

People

(Reporter: gsvelto, Assigned: morgan)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Crash report: https://crash-stats.mozilla.org/report/index/45ce1fc9-2c33-4b55-a9ba-96a030230624

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  mozilla::a11y::RemoteAccessibleBase<mozilla::a11y::RemoteAccessible>::DoFuzzyHittesting  accessible/ipc/RemoteAccessibleBase.cpp:446
1  xul.dll  mozilla::a11y::RemoteAccessibleBase<mozilla::a11y::RemoteAccessible>::ChildAtPoint  accessible/ipc/RemoteAccessibleBase.cpp:562
2  xul.dll  mozilla::a11y::OuterDocAccessible::ChildAtPoint  accessible/generic/OuterDocAccessible.cpp:214
3  xul.dll  mozilla::a11y::MsaaAccessible::accHitTest  accessible/windows/msaa/MsaaAccessible.cpp:1281
4  rpcrt4.dll  Invoke  
5  rpcrt4.dll  NdrStubCall2  
6  ole32.dll  CStdStubBuffer_Invoke  d:\w7rtm\com\rpc\ndrole\stub.cxx:1505
7  oleaut32.dll  virtual long __stdcall CUnivStubWrapper::Invoke  
8  ole32.dll  SyncStubInvoke  d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx:1187
9  ole32.dll  StubInvoke  

This appears to be a new crash, possibly a regression since it's only happening on nightly. From a very quick glance it seems like child might be NULL here.

I agree it does look like child might be null there, but I don't see how and I really hope that's not true. RemoteAccessible::RemoteChildAt shouldn't be able to return null when called with an index less than RemoteAccessible::ChildCount.

Regressed by: 1837024

Oh durp. We set maybeTextLeaf here, but we deliberately don't break out of the loop. However, the loop still assumes maybeTextLeaf is unchanged and tries to call RemoteChildAt on it, but we're now dealing with a descendant! I suspected something wasn't quite right with this loop when I reviewed it, but I couldn't quite figure out what it was despite reading it many times and ended up putting it down to me being thick. :)

Set release status flags based on info from the regressing bug 1837024

:morgan, since you are the author of the regressor, bug 1837024, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(mreschenberg)
Assignee: nobody → mreschenberg
Flags: needinfo?(mreschenberg)

Just as a reminder, tomorrow is soft freeze for 116 in case we wanted to land this soon :)

Pushed by mreschenberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4570141f12e9 Track containers and text leaves separately when fuzzy hittesting r=Jamie
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch
Crash Signature: [@ mozilla::a11y::RemoteAccessibleBase<T>::DoFuzzyHittesting] → [@ mozilla::a11y::RemoteAccessibleBase<T>::DoFuzzyHittesting] [@ mozilla::a11y::RemoteAccessible::DoFuzzyHittesting]
Duplicate of this bug: 1841443

Set release status flags based on info from the regressing bug 1837024

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: