Closed Bug 1581719 Opened 5 months ago Closed 3 months ago

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

Categories

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

Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: m_kato, Assigned: Jamie)

Details

Attachments

(1 file)

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]

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jteh)

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

Flags: needinfo?(jteh)
Priority: -- → P1

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.

Assignee: nobody → jteh
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4b4d691f63da
Change QI assertion in AccessibleWrap::GetRemoteIAccessibleFor to a warning. r=MarcoZ
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
You need to log in before you can comment on or make changes to this bug.