>> gambard: https://chromium-review.googlesource.com/1068727
>> eugenebut: https://chromium-review.googlesource.com/1068257
These only change //ios code, which can't break Mac. 

yeah, they were a little hopeful i'll admit. :/ i'll try repro locally on my ancient mac, i guess.

going to try to track down for assignment...

My 2014 MBP is just about to light on fire! But also:

$ git bisect bad
3a2babeb82b88d78f4c47efac8078496ab50fbc3 is the first bad commit
commit 3a2babeb82b88d78f4c47efac8078496ab50fbc3
Author: Sylvain Defresne <sdefresne@chromium.org>
Date:   Tue May 22 16:19:46 2018 +0000

    Add supports for Objective-C blocks to base::Bind*

    Add template specifialization allowing to use base::Bind* with
    Objective-C block. To avoid breaking ODR, it is necessary to
    use base::WrapBlock() when ARC support is disabled, but when
    it is enabled, the block can be directly bound by base::Bind*.

    This also allow to use base::BindOnce() with blocks and thus
    pass them  move-only objects, allowing the following:

      __weak Foo* weakSelf = self;
      std::unique_ptr<Bar> bar = ...;
      base::OnceClosure closure = base::BindOnce(
          ^(std::unique_ptr<Bar> bar) {
              [weakSelf adoptBar:std::move(bar)];
          }, std::move(bar));

    The base::BindBlock and base::BindBlockArc templates are kept for
    compatibility but are now just wrapper for base::BindRepeating.

    Bug:  701275 
    Change-Id: I6e5d5309bcae768b2d1e8425b27ca295098e30b1
    Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
    Reviewed-on: https://chromium-review.googlesource.com/977912
    Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
    Reviewed-by: Taiju Tsuiki <tzik@chromium.org>
    Reviewed-by: Nico Weber <thakis@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#560634}

:040000 040000 34d3a885111aa05dab663ff6e635ddff627980c6 7e14885929a9051bfef6a115bb824a291d9e0dd1 M	base

Currently, we're observing many Mac-only flakiness, e.g.  bug 845760 ,  bug 845759 ,
 bug 845690 . I can see two types of failures:

* Type A:
[ RUN      ] DownloadsListTrackerTest.SetSearchTerms
[50324:775:0522/194224.473585:29431315553951:FATAL:sequenced_task_runner_handle.cc(33)] Check failed: ThreadTaskRunnerHandle::IsSet(). Error: This caller requires a sequenced context (i.e. the current task needs to run from a SequencedTaskRunner).
0   unit_tests                          0x00000001072ce41c base::debug::StackTrace::StackTrace(unsigned long) + 28
1   unit_tests                          0x00000001071ea10f logging::LogMessage::~LogMessage() + 223
2   unit_tests                          0x00000001072893cb base::SequencedTaskRunnerHandle::Get() + 139
3   unit_tests                          0x00000001066315bf mojo::internal::GetTaskRunnerToUseFromUserProvidedTaskRunner(scoped_refptr<base::SequencedTaskRunner>) + 127
4   unit_tests                          0x0000000106623087 mojo::internal::InterfacePtrStateBase::Bind(mojo::ScopedHandleBase<mojo::MessagePipeHandle>, unsigned int, scoped_refptr<base::SequencedTaskRunner>) + 471
5   unit_tests                          0x00000001077d0ade mojo::internal::InterfacePtrState<resource_coordinator::mojom::PageSignalGenerator>::Bind(mojo::InterfacePtrInfo<resource_coordinator::mojom::PageSignalGenerator>, scoped_refptr<base::SequencedTaskRunner>) + 142
6   unit_tests                          0x00000001077d0a0d mojo::InterfacePtr<resource_coordinator::mojom::PageSignalGenerator>::Bind(mojo::InterfacePtrInfo<resource_coordinator::mojom::PageSignalGenerator>, scoped_refptr<base::SequencedTaskRunner>) + 157

* Type B:
[ RUN      ] BrowserViewHostedAppTest.Layout
Received signal 4 <unknown> 00010a880193
0   unit_tests                          0x000000010a99541c base::debug::StackTrace::StackTrace(unsigned long) + 28
1   unit_tests                          0x000000010a995241 base::debug::(anonymous namespace)::StackDumpSignalHandler(int, __siginfo*, void*) + 2401
2   libsystem_platform.dylib            0x00007fff75818f5a _sigtramp + 26
3   ???                                 0x0000000000000004 0x0 + 4
4   unit_tests                          0x000000010a887bd7 base::AtExitManager::~AtExitManager() + 135
5   unit_tests                          0x00000001056f2e77 BrowserWithTestWindowTest::~BrowserWithTestWindowTest() + 183
6   unit_tests                          0x0000000106760aee BrowserViewHostedAppTest_Layout_Test::~BrowserViewHostedAppTest_Layout_Test() + 14

Out of this, the Type B suggests the relationship with the CL identified above,
because AtExitManager's destructor runs base::Closure. The Type A might be
related, too.

The effect of this CL seems rather large, so I'm going to revert the CL
to fix the widespread failures.

 Issue 845760  has been merged into this issue.

 Issue 846092  has been merged into this issue.

The CL reverted was the cause of the flakyness as it introduced undefined behaviour (use after free). The UB has been fixed by the reland (https://chromium-review.googlesource.com/c/chromium/src/+/1070158).