New issue
Advanced search Search tips

Issue 869151 link

Starred by 1 user
Status: WontFix
Owner:
brucedaw...@chromium.org
Closed: Jul 30
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 869154



Sign in to add a comment

Invalid process handle in ForceNormalProcessTerminationSync

Project Member Reported by brucedaw...@chromium.org, Jul 30 
While testing a fix for crbug.com/868341 I hit this failure:

:FATAL:process_handle_win.cc(29)] Check failed: result != 0 || GetLastError() != ERROR_INVALID_HANDLE. process handle = 0000000000000D5C
Backtrace:
        base::debug::StackTrace::StackTrace [0x00007FF71A049C14+36] (c:\src\chromium3\src\base\debug\stack_trace_win.cc:286)
        logging::LogMessage::~LogMessage [0x00007FF71A062035+101] (c:\src\chromium3\src\base\logging.cc:593)
        base::GetProcId [0x00007FF71A08696F+127] (c:\src\chromium3\src\base\process\process_handle_win.cc:0)
        base::Process::Terminate [0x00007FF71A0879AF+255] (c:\src\chromium3\src\base\process\process_win.cc:154)
        content::internal::ChildProcessLauncherHelper::ForceNormalProcessTerminationSync [0x00007FF718EEEA52+18] (c:\src\chromium3\src\content\browser\child_process_launcher_helper_win.cc:110)
        base::internal::Invoker<base::internal::BindState<void (*)(content::internal::ChildProcessLauncherHelper::Process),content::internal::ChildProcessLauncherHelper::Process>,void ()>::RunOnce [0x00007FF718EEE73F+47] (c:\src\chromium3\src\base\bind_internal.h:658)
        base::debug::TaskAnnotator::RunTask [0x00007FF71ABAB51C+300] (c:\src\chromium3\src\base\debug\task_annotator.cc:101)
        base::internal::TaskTracker::RunOrSkipTask [0x00007FF71AB9838E+926] (c:\src\chromium3\src\base\task_scheduler\task_tracker.cc:530)
        base::internal::TaskTracker::RunAndPopNextTask [0x00007FF71AB97AB5+309] (c:\src\chromium3\src\base\task_scheduler\task_tracker.cc:404)
        base::internal::SchedulerWorker::RunWorker [0x00007FF71C4679B2+866] (c:\src\chromium3\src\base\task_scheduler\scheduler_worker.cc:329)
        base::internal::SchedulerWorker::RunDedicatedWorker [0x00007FF71C4675B0+32] (c:\src\chromium3\src\base\task_scheduler\scheduler_worker.cc:248)
        base::`anonymous namespace'::ThreadFunc [0x00007FF71A0AC184+244] (c:\src\chromium3\src\base\threading\platform_thread_win.cc:94)
        BaseThreadInitThunk [0x00007FFFA2CE1FE4+20]
        RtlUserThreadStart [0x00007FFFA3D7CB31+33]

Code examination suggests that this is impossible. ForceNormalProcessTerminationSync calls Terminate on the base::Process object owned by ChildProcessLauncherHelper. On Windows base::Process *owns* the process handle, using win::ScopedHandle, so I don't see how this bug can happen.

The failure checks in GetProcId were patched in from the (since reverted) crrev.com/c/1145767, and then a fix for crbug.com/868341 was patched in.

The command line to repro this failure was:

> sync_integration_tests --gtest_filter=SingleClientAppsSyncTest.StartWithSomePlatformApps --gtest_repeat=3

This failure has been seen multiple times.

Comment 1 by brucedaw...@chromium.org, Jul 30

Blocking: 869154

Comment 2 by brucedaw...@chromium.org, Jul 30 

Debugging makes it clearer what is going on, but also more confusing. This is the fragment of code that fails

    if (::WaitForSingleObject(Handle(), kWaitMs) == WAIT_OBJECT_0) {
      DWORD actual_exit;
      Exited(::GetExitCodeProcess(Handle(), &actual_exit) ? actual_exit
                                                          : exit_code);

Exited() is not on the call stack but it calls GetProcId so presumably it was inlined (this was a release build) and GetProcId then failed. Since the WaitForSingleObject call succeeded (it returned WAIT_OBJECT_0) this means that the handle *was* valid and was then signaled, but then became invalid. This suggests, I think, that somebody else closed our handle, but the ChildProcessLauncherHelper::Process object is a local variable so that should be impossible. ChildProcessLauncherHelper::Process uses DuplicateHandle to copy itself so this all seems impossible.

Comment 3 by brucedaw...@chromium.org, Jul 30

Status: WontFix (was: Assigned)
This was a spurious failure caused by a buggy fix to another bug. Closing as WontFix.
►

Sign in to add a comment