New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 631143 link

Starred by 2 users
Status: WontFix
Owner:
█ roc...@chromium.org
please use my google.com address
Closed: Sep 2016
Cc:
sadrul@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Cannot send handles via ChannelHandle backed by mojo IPC on Windows

Project Member Reported by penghuang@chromium.org, Jul 25 2016 

See the log:
[129/190] WindowFinderTest.FindDeepestVisibleWindowHitTestMask (0 ms)
[ RUN      ] WindowServerTest.RootWindow

[0711/110756:ERROR:command_buffer_proxy_impl.cc(232)] Failed to send GpuChannelMsg_CreateCommandBuffer.

Backtrace:

	gpu::CommandBufferProxyImpl::CheckLock [0x000007FEEC5F05B2+14]

	gpu::CommandBufferProxyImpl::SetSwapBuffersCompletionCallback [0x000007FEEC5F28D9+21]

	ui::SurfacesContextProvider::SurfacesContextProvider [0x000007FEEC63C8BC+608]

	ui::DisplayCompositor::DisplayCompositor [0x000007FEEC63C037+259]

	ui::ws::FrameGenerator::OnAcceleratedWidgetAvailable [0x000007FEEC64A1A4+84]

	ui::ws::DefaultPlatformDisplay::OnAcceleratedWidgetAvailable [0x000007FEEC64BC16+26]

	ui::WinWindow::_ProcessWindowMessage [0x000007FEECA29CA6+486]

	ui::WinWindow::ProcessWindowMessage [0x000007FEECA29980+56]

	gfx::WindowImpl::OnWndProc [0x000007FEECA5FE98+84]

	gfx::WindowImpl::WndProc [0x000007FEECA602C8+180]

	base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc> [0x000007FEECA5F7DF+15]

	GetWindowDC [0x00000000777A8971+129]

	SetWindowTextW [0x00000000777A72CB+631]

	SendMessageTimeoutW [0x00000000777A0795+3285]

	KiUserCallbackDispatcher [0x00000000778DD8F5+31]

	SendMessageTimeoutW [0x00000000777A041A+2394]

	SendMessageTimeoutW [0x00000000777A0397+2263]

	SendMessageTimeoutW [0x00000000777A05D8+2840]

	CreateWindowExW [0x00000000777A0880+112]

	gfx::WindowImpl::Init [0x000007FEECA5FC28+380]

	ui::WinWindow::WinWindow [0x000007FEECA29493+191]

	ui::ws::DefaultPlatformDisplay::Init [0x000007FEEC64BBB8+64]

	ui::ws::Display::Display [0x000007FEEC64286D+377]

	ui::ws::WindowTreeHostFactory::CreateWindowTreeHost [0x000007FEEC66687F+67]

	ui::mojom::WindowTreeHostFactoryStub::Accept [0x000007FEEC52A91F+711]

	mojo::internal::Router::HandleMessageInternal [0x000007FEEC503755+733]

	mojo::internal::Router::HandleIncomingMessage [0x000007FEEC503462+454]

	ui::mojom::WindowTreeHostFactoryRequestValidator::Accept [0x000007FEEC52A638+192]

	mojo::MessageHeaderValidator::Accept [0x000007FEEC4FBA96+218]

	mojo::Connector::ReadSingleMessage [0x000007FEEC4F7933+179]

	mojo::Connector::ReadAllAvailableMessages [0x000007FEEC4F785B+31]

	mojo::Connector::OnHandleReadyInternal [0x000007FEEC4F75B4+140]

	mojo::Watcher::OnHandleReady [0x000007FEEC50732A+186]

	base::internal::Invoker<base::internal::BindState<void (__cdecl mojo::Watcher::*)(unsigned int) __ptr64,base::WeakPtr<mojo::Watcher>,unsigned int>,void __cdecl(void)>::RunImpl<void (__cdecl mojo::Watcher::*const & __ptr64)(unsigned int) __ptr64,std::tuple [0x000007FEEC9EE026+86]

	base::debug::TaskAnnotator::RunTask [0x000007FEEC6A60AC+316]

	base::MessageLoop::RunTask [0x000007FEEC66D41C+876]

	base::MessageLoop::DoWork [0x000007FEEC66C82B+411]

	base::MessagePumpForUI::DoRunLoop [0x000007FEEC6A75A8+120]

	base::MessagePumpWin::Run [0x000007FEEC6A8474+84]

	base::RunLoop::Run [0x000007FEEC67BB6E+46]

	shell::ApplicationRunner::Run [0x000007FEEC4F0B41+369]

	MojoMain [0x000007FEEC4E88B9+73]

	shell::RunNativeApplication [0x000000013F416F9D+293]

	base::internal::Invoker<base::internal::BindState<void (__cdecl*)(HINSTANCE__ * __ptr64,mojo::InterfaceRequest<shell::mojom::Service>),HINSTANCE__ * __ptr64>,void __cdecl(mojo::InterfaceRequest<shell::mojom::Service>)>::Run [0x000000013F414E2D+113]

	base::internal::Invoker<base::internal::BindState<void (__cdecl*)(HINSTANCE__ * __ptr64,mojo::InterfaceRequest<shell::mojom::Service>),HINSTANCE__ * __ptr64>,void __cdecl(mojo::InterfaceRequest<shell::mojom::Service>)>::Run [0x000000013F414DE8+44]

	shell::ChildProcessMainWithCallback [0x000000013F416B57+575]

	shell::ChildProcessMain [0x000000013F414D83+343]

	main [0x000000013F41707C+76]

	__scrt_common_main_seh [0x000000013F859DC4+292] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255)

	BaseThreadInitThunk [0x0000000077685A4D+13]

	RtlUserThreadStart [0x00000000778BB831+33]

[4856:4144:0711/110757:8367176:ERROR:node_channel.cc(828)] Failed to duplicate one or more outgoing handles.

e:\b\build\slave\win\build\src\services\ui\public\cpp\tests\window_server_test_base.cc(72): error: Value of: DoRunLoopWithTimeout()

  Actual: false

Expected: true

[4468:3608:0711/110806:8376645:ERROR:node_controller.cc(1066)] Could not be introduced to peer 245332288C7573A2.2C2C1C4667CC55EC

[  FAILED  ] WindowServerTest.RootWindow (10079 ms)

Comment 1 by roc...@chromium.org, Jul 27 2016

Cc: sadrul@chromium.org
I just noticed r408207 landed. Does that mean this bug is obsolete or is there still something that isn't working as expected?

Comment 2 by penghuang@chromium.org, Jul 27 2016

Status: WontFix (was: Assigned)
The issue is disappeared, but we didn't do anything. I thought you fixed it. :)
Anyway, I think we can close it.

Comment 3 by roc...@chromium.org, Jul 27 2016

Blocking: -623157
Labels: -Pri-1 Pri-2
Status: Assigned (was: WontFix)
Ah hmm, perhaps it's a bug with ChannelWin carrying an IPC::ChannelHandle which wraps a Mojo handle. This would have been "fixed" by switching GpuChannel to use ChannelMojo, which was landed recently.

I'm going to keep this open for myself to investigate at a lower priority, since there are other ChannelWin uses remaining; though none of them need to carry MojoHandles at the moment.

Comment 4 by roc...@chromium.org, Sep 27 2016

Components: Internals>Mojo
Status: WontFix (was: Assigned)
I don't see anything obviously broken here and there's no known use case for it if it were broken. Gonna close this.
►

Sign in to add a comment