commit 5ced2c85be2a0d0cb4ac73933578a4373fcb4275
author Sami Kyostila <skyostil@chromium.org> Fri Dec 07 10:36:43 2018
committer Commit Bot <commit-bot@chromium.org> Fri Dec 07 10:36:43 2018
tree 9491d23cd295c11bdce3e87eaa75d64fb3fa2e1a
parent 981c863d9c656cdec1019c3d795cbc96b71cbfcc

mac: Add workaround for native run loop live-lock

This patch adds a workaround and a test for a scenario where the invalidation
of the delayed work timer (using non-public APIs) causes a nested native run
loop to hang. The exact root cause of the hang is unknown since it involves the
closed-source Core Foundation runtime, but the steps needed to trigger it are:

  1. Post a delayed task that will run some time after step #4.
  2. Allow Chrome tasks to run in nested run loops (with
     ScopedNestableTaskAllower).
  3. Allow running Chrome tasks during private run loop modes (with
     ScopedPumpMessagesInPrivateModes).
  4. Open a pop-up menu via [NSMenu popupContextMenu]. This will start a
     private native run loop to process menu interaction.
  5. In a posted task, close the menu with [NSMenu cancelTracking].

At this point the menu closes visually but the nested run loop (flakily)
hangs forever in a live-lock, i.e., Chrome tasks keep executing but the
NSMenu call in #4 never returns.

The workaround is to avoid timer invalidation during nested native run loops.

DANGER: As the pop-up menu captures keyboard input, the bug will make the
machine's keyboard inoperable during the live-lock. Use a TTY-based remote
terminal such as SSH (as opposed to Chromoting) to investigate the issue.

Bug: 912273, 891670
Change-Id: I76562ddbf45f714397d7cb385f5f690d64e377d0
Reviewed-on: https://chromium-review.googlesource.com/c/1363208
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614658}