1329697 - Assertion failure: found, at c:/gecko-dev/ipc/mscom/Interceptor.cpp:119

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Yura Zenevich [:yzen] (please use "needinfo")]

This happens when IGeckoCustom interface gets queried with e10s enabled.

Assertion failure: found, at c:/gecko-dev/ipc/mscom/Interceptor.cpp:119
#01: mozilla::mscom::Interceptor::GetInterceptorForIID (c:\gecko-dev\ipc\mscom\interceptor.cpp:208)
#02: mozilla::mscom::Interceptor::ThreadSafeQueryInterface (c:\gecko-dev\ipc\mscom\interceptor.cpp:294)
#03: mozilla::mscom::WeakReferenceSupport::QueryInterface (c:\gecko-dev\ipc\mscom\weakref.cpp:48)
#04: CoCreateFreeThreadedMarshaler[C:\WINDOWS\System32\combase.dll +0xac137]
#05: CoCreateFreeThreadedMarshaler[C:\WINDOWS\System32\combase.dll +0xaf156]
#06: CoCreateFreeThreadedMarshaler[C:\WINDOWS\System32\combase.dll +0xaf90d]
#07: CoGetCallContext[C:\WINDOWS\System32\combase.dll +0x918f0]
#08: NdrNsSendReceive[C:\WINDOWS\System32\RPCRT4.dll +0x42324]
#09: NdrStubCall2[C:\WINDOWS\System32\RPCRT4.dll +0x4f9b]
#10: CStdStubBuffer_Invoke[C:\WINDOWS\System32\combase.dll +0x23279]
#11: CoGetCallContext[C:\WINDOWS\System32\combase.dll +0x967c6]
#12: CoGetCallContext[C:\WINDOWS\System32\combase.dll +0x96b2f]
#13: CoGetCallContext[C:\WINDOWS\System32\combase.dll +0x9d378]
#14: CoGetCallContext[C:\WINDOWS\System32\combase.dll +0x938a2]
#15: CoGetCallContext[C:\WINDOWS\System32\combase.dll +0x9b92e]
#16: CoGetCallContext[C:\WINDOWS\System32\combase.dll +0x98932]
#17: I_RpcGetBuffer[C:\WINDOWS\System32\RPCRT4.dll +0x24eb0]
#18: I_RpcGetBuffer[C:\WINDOWS\System32\RPCRT4.dll +0x2481f]
#19: I_RpcGetBuffer[C:\WINDOWS\System32\RPCRT4.dll +0x24be7]
#20: I_RpcGetBuffer[C:\WINDOWS\System32\RPCRT4.dll +0x25b47]
#21: I_RpcGetBuffer[C:\WINDOWS\System32\RPCRT4.dll +0x25fc5]
#22: I_RpcReceive[C:\WINDOWS\System32\RPCRT4.dll +0x2a870]
#23: I_RpcReceive[C:\WINDOWS\System32\RPCRT4.dll +0x2b164]
#24: RpcBindingSetAuthInfoExW[C:\WINDOWS\System32\RPCRT4.dll +0x21694]
#25: TpCallbackMayRunLong[C:\WINDOWS\SYSTEM32\ntdll.dll +0x29989]
#26: TpReleaseTimer[C:\WINDOWS\SYSTEM32\ntdll.dll +0x36d3f]
#27: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x162c4]
#28: RtlSubscribeWnfStateChangeNotification[C:\WINDOWS\SYSTEM32\ntdll.dll +0x60fd9]
#29: RtlSubscribeWnfStateChangeNotification[C:\WINDOWS\SYSTEM32\ntdll.dll +0x60fa4]

Comment 1

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: 1329697 patch

This seems to address the issue, I'm not sure though if it's done as expected.

It seems though even with this patch IGeckoCustom is never resolved when queried for as this call https://dxr.mozilla.org/mozilla-central/source/accessible/ipc/win/ProxyAccessible.cpp?q=if+%28FAILED%28acc-%3EQueryInterface%28InterfaceIID%3CInterface%3E%3A%3AValue%28%29%2C&redirect_type=single#97 always fails. 

I looked at it a little closer and it seems like QueryInterface call in child process succeeds so I'm not sure at what point the failure happens. Aaron would you have a moment and perhaps some ideas about this?

The issue can be easily seen when running any of the accessibility browser tests (/accessible/tests/browser/e10s/browser_events_hide.js for example) with current trunk + patch from bug 1269369 + this patch

Comment 2

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: 1329697 v2

This is a slightly modified version of the first patch. I'm doing similar things to how Accessible.tlb is registered but for IGeckoCustom. The assertion is now fixed however the interface (though resolving in child) never gets resolved in parent. Thanks for taking a look, Aaron!

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8825819 [details] [diff] [review]
1329697 v2

Review of attachment 8825819 [details] [diff] [review]:
-----------------------------------------------------------------

My main concern with doing it this way is that we are exposing IGeckoCustom to the file system (and to third-party developers who know just enough to be dangerous looking around in there).

IIRC, Trevor's patch already embeds IGeckoCustom.tlb into the resources for xul.dll, so you should just be able to call mscom::RegisterTypelib(L"xul.dll").

Comment 4

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: 1329697 v3

verified DOMNodeID is resolving correctly from IGeckoCustom

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8827985 [details] [diff] [review]
1329697 v3

Review of attachment 8827985 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/ipc/win/PlatformChild.cpp
@@ +47,5 @@
>          mozilla::mscom::RegistrationFlags::eUseSystemDirectory))
>    , mMiscTypelib(mozilla::mscom::RegisterTypelib(L"Accessible.tlb"))
>  {
>    mozilla::mscom::InterceptorLog::Init();
>    mozilla::mscom::RegisterArrayData(sPlatformChildArrayData);

Add a blank line here, please.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3df827c3c6da
registering typelib for IGeckoCustom interface. r=aklotz

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3df827c3c6da