New issue
Advanced search Search tips

Issue 868490 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner:
Closed: Jul 27
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Invalid process handles in ChildConnection::IOThreadContext

Project Member Reported by brucedaw...@chromium.org, Jul 27

Issue description

After landing crrev.com/c/1145767 there were flaky failures in SingleClientAppsSyncTest.StartWithSomePlatformApps. The failure call stack is:

[5744:6016:0727/011726.878:FATAL:process_handle_win.cc(29)] Check failed: result != 0 || GetLastError() != ERROR_INVALID_HANDLE. process handle = 00000FB4
Backtrace:
	base::debug::StackTrace::StackTrace [0x73D7A1D6+102]
	base::debug::StackTrace::StackTrace [0x73D7927B+27]
	logging::LogMessage::~LogMessage [0x73DDEFA4+148]
	base::GetProcId [0x73EC8E8E+254]
	content::ChildConnection::IOThreadContext::SetProcessHandleOnIOThread [0x617A7C58+232]
	base::internal::FunctorTraits<void (__thiscall content::ChildConnection::IOThreadContext::*)(void *),void>::Invoke<void (__thiscall content::ChildConnection::IOThreadContext::*)(void *),scoped_refptr<content::ChildConnection::IOThreadContext>,void *> [0x617A8001+81]
	base::internal::InvokeHelper<0,void>::MakeItSo<void (__thiscall content::ChildConnection::IOThreadContext::*)(void *),scoped_refptr<content::ChildConnection::IOThreadContext>,void *> [0x617A7F0C+124]
	base::internal::Invoker<base::internal::BindState<void (__thiscall content::ChildConnection::IOThreadContext::*)(void *),scoped_refptr<content::ChildConnection::IOThreadContext>,void *>,void __cdecl(void)>::RunImpl<void (__thiscall content::ChildConnectio [0x617A7E3F+111]
	base::internal::Invoker<base::internal::BindState<void (__thiscall content::ChildConnection::IOThreadContext::*)(void *),scoped_refptr<content::ChildConnection::IOThreadContext>,void *>,void __cdecl(void)>::RunOnce [0x617A7CE4+84]
	base::OnceCallback<void __cdecl(void)>::Run [0x73D1CA90+80]
	base::debug::TaskAnnotator::RunTask [0x73D7E9F3+1075]
	base::MessageLoop::RunTask [0x73E19A64+884]
	base::MessageLoop::DeferOrRunPendingTask [0x73E1A249+73]
	base::MessageLoop::DoWork [0x73E1A5BA+442]
	base::MessagePumpForIO::DoRunLoop [0x73E2775C+28]
	base::MessagePumpWin::Run [0x73E25CA7+119]
	base::MessageLoop::Run [0x73E19366+486]
	base::RunLoop::Run [0x73EDF518+488]
	base::Thread::Run [0x73FF8EF7+375]
	content::BrowserProcessSubThread::IOThreadRun [0x61B456A0+48]
	content::BrowserProcessSubThread::Run [0x61B45589+313]
	base::Thread::ThreadMain [0x73FF97BA+1402]
	base::PlatformThread::GetCurrentThreadPriority [0x73FEBC76+934]
	BaseThreadInitThunk [0x74AD336A+18]
	RtlInitializeExceptionChain [0x771F9902+99]
	RtlInitializeExceptionChain [0x771F98D5+54]

The initial cause is simple enough - a raw process handle is passed to a different thread and becomes invalid before the handle arrives.

The initial fix is obvious enough - convert from a handle to a process ID before making the cross-thread call. However this may just move the race condition from using a handle after it is freed to using a process ID after it is freed.

Adding a two second Sleep to content::ChildConnection::IOThreadContext::SetProcessHandleOnIOThread while having crrev.com/c/1145767 patched in is the best way to reproduce the initial test failures.

 
Mergedinto: 868341
Status: Duplicate (was: Started)

Sign in to add a comment