1581719 - Assertion failure: (((HRESULT)(hr)) >= 0), at m:/mozilla-central/accessible/windows/msaa/AccessibleWrap.cpp:1570

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

[Makoto Kato [:m_kato] (fever, slow response)]

When running a mochitest on my Windows workstation, it sometime hits the following assertion. I use ATOK (IME) and/or Microsoft IME that is a11y application. So could you change this assertion to warning or fix this assertion?

already_AddRefed<IAccessible> AccessibleWrap::GetRemoteIAccessibleFor(
    const VARIANT& aVarChild) {
...
    DebugOnly<HRESULT> hr =
        disp->QueryInterface(IID_IAccessible, getter_AddRefs(result));
    MOZ_ASSERT(SUCCEEDED(hr));

Stack is the following.

 0:17.32 GECKO(2612) Assertion failure: (((HRESULT)(hr)) >= 0), at m:/mozilla-central/accessible/windows/msaa/AccessibleWrap.cpp:1570
 0:18.12 GECKO(2612) --DOCSHELL 0000020D88E58800 == 3 [pid = 3340] [id = {5896d755-2344-4edd-8db0-662c032adb6a}] [url = moz-extension://e1a6a130-9fa1-46ed-8649-4656dcb595fa/_generated_background_page.html]
 0:18.70 GECKO(2612) #01: mozilla::a11y::AccessibleWrap::get_accChild (m:\mozilla-central\accessible\windows\msaa\AccessibleWrap.cpp:257)
 0:18.71 GECKO(2612) #02: mozilla::a11y::LazyInstantiator::get_accChild (m:\mozilla-central\accessible\windows\msaa\LazyInstantiator.cpp:523)
 0:18.71 GECKO(2612) #03: NdrSendReceive[C:\WINDOWS\System32\RPCRT4.dll +0x76963]
 0:18.71 GECKO(2612) #04: NdrStubCall2[C:\WINDOWS\System32\RPCRT4.dll +0x1364b]
 0:18.71 GECKO(2612) #05: NdrStubCall3[C:\WINDOWS\System32\RPCRT4.dll +0x382b3]
 0:18.71 GECKO(2612) #06: CStdStubBuffer_Invoke[C:\WINDOWS\System32\combase.dll+0xa0e93]
 0:18.71 GECKO(2612) #07: CStdStubBuffer_Invoke[C:\WINDOWS\System32\RPCRT4.dll +0x59a8b]
 0:18.71 GECKO(2612) #08: WindowsStringHasEmbeddedNull[C:\WINDOWS\System32\combase.dll +0x8e663]
 0:18.71 GECKO(2612) #09: WindowsStringHasEmbeddedNull[C:\WINDOWS\System32\combase.dll +0x8e453]
 0:18.71 GECKO(2612) #10: WindowsGetStringLen[C:\WINDOWS\System32\combase.dll +0xa4526]
 0:18.71 GECKO(2612) #11: CoGetMarshalSizeMax[C:\WINDOWS\System32\combase.dll +0x52d7a]
 0:18.71 GECKO(2612) #12: CoWaitForMultipleHandles[C:\WINDOWS\System32\combase.dll +0x45fed]
 0:18.71 GECKO(2612) #13: CoMarshalInterface[C:\WINDOWS\System32\combase.dll +0x616ac]
 0:18.71 GECKO(2612) #14: CoMarshalInterface[C:\WINDOWS\System32\combase.dll +0x61f11]
 0:18.71 GECKO(2612) #15: Ordinal86[C:\WINDOWS\System32\combase.dll +0x4a79d]
 0:18.71 GECKO(2612) #16: CallWindowProcW[C:\WINDOWS\System32\user32.dll +0x1681d]
 0:18.71 GECKO(2612) #17: DispatchMessageW[C:\WINDOWS\System32\user32.dll +0x16212]
 0:18.71 GECKO(2612) #18: nsAppShell::ProcessNextNativeEvent (m:\mozilla-central\widget\windows\nsAppShell.cpp:554)
 0:18.73 GECKO(2612) #19: nsBaseAppShell::OnProcessNextEvent (m:\mozilla-central\widget\nsBaseAppShell.cpp:259)
 0:18.74 GECKO(2612) #20: nsThread::ProcessNextEvent (m:\mozilla-central\xpcom\threads\nsThread.cpp:1121)
 0:18.74 GECKO(2612) #21: NS_ProcessNextEvent (m:\mozilla-central\xpcom\threads\nsThreadUtils.cpp:486)
 0:18.76 GECKO(2612) #22: mozilla::ipc::MessagePump::Run (m:\mozilla-central\ipc\glue\MessagePump.cpp:88)
 0:18.77 GECKO(2612) #23: MessageLoop::RunHandler (m:\mozilla-central\ipc\chromium\src\base\message_loop.cc:309)
 0:18.77 GECKO(2612) #24: MessageLoop::Run (m:\mozilla-central\ipc\chromium\src\base\message_loop.cc:291)
 0:18.77 GECKO(2612) #25: nsBaseAppShell::Run (m:\mozilla-central\widgetnsBaseAppShell.cpp:139)
 0:18.77 GECKO(2612) #26: nsAppShell::Run (m:\mozilla-central\widget\windows\nsAppShell.cpp:406)
 0:18.77 GECKO(2612) #27: nsAppStartup::Run (m:\mozilla-central\toolkit\components\startup\nsAppStartup.cpp:277)
 0:18.79 GECKO(2612) #28: XREMain::XRE_mainRun (m:\mozilla-central\toolkit\xre\nsAppRunner.cpp:4600)
 0:18.79 GECKO(2612) #29: XREMain::XRE_main (m:\mozilla-central\toolkit\xre\nsAppRunner.cpp:4735)
 0:18.79 GECKO(2612) #30: XRE_main (m:\mozilla-central\toolkit\xre\nsAppRunner.cpp:4816)
 0:18.79 GECKO(2612) #31: NS_internal_main (m:\mozilla-central\browser\app\nsBrowserApp.cpp:300)
 0:18.79 GECKO(2612) #32: wmain (m:\mozilla-central\toolkit\xre\nsWindowsWMain.cpp:131)
 0:18.79 GECKO(2612) #33: __scrt_common_main_seh (d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
 0:18.79 GECKO(2612) #34: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x17bd4]
 0:18.79 GECKO(2612) #35: RtlUserThreadStart[C:\WINDOWS\SYSTEM32\ntdll.dll +0x6cee1]

Comment 1

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

The priority flag is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[James Teh [:Jamie]]

I guess the remote Accessible must have died just after we fetched it?

Comment 3

[Intermittent Failures Robot]

3 failures in 4292 pushes (0.001 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 3

Platform breakdown:

• windows10-64-qr: 3

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1581719&startday=2019-09-30&endday=2019-10-06&tree=all

Comment 4

[James Teh [:Jamie]]

Attachment: Bug 1581719: Change QI assertion in AccessibleWrap::GetRemoteIAccessibleFor to a warning.

Sometimes, when running tests, fetching IDispatch for a remote IAccessible succeeds, but QueryInterface to IAccessible fails.
This is probably because the remote Accessible died between these two calls.
While we want to know about this in case of real problems in future, it usually doesn't indicate a problem, so make it a warning.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4b4d691f63da
Change QI assertion in AccessibleWrap::GetRemoteIAccessibleFor to a warning. r=MarcoZ

Comment 6

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/4b4d691f63da