This has been happening since at least Oct 15th, and possibly since the test was changed last:
https://uberchromegw.corp.google.com/i/chromium.memory/builders/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/builds/24175

ssid, can you please investigate this?

The flaky failure does not reproduce locally and the output from bot only shows the bottom half of the stack trace which is completely useless. I have no way to find out what's going on.

The output:
<truncated (503900 bytes)>
ic/cpp/bindings/lib/connector.cc:440:51
    #15 0x116f9d37 in mojo::Connector::ReadAllAvailableMessages() mojo/public/cpp/bindings/lib/connector.cc:469:10
    #16 0x116f96e3 in mojo::Connector::OnHandleReadyInternal(unsigned int) mojo/public/cpp/bindings/lib/connector.cc:374:3
    #17 0x759f77f in Run base/callback.h:92:12
    #18 0x759f77f in mojo::SimpleWatcher::DiscardReadyState(base::RepeatingCallback<void (unsigned int)> const&, unsigned int, mojo::HandleSignalsState const&) mojo/public/cpp/system/simple_watcher.h:193
    #19 0x116e0dbe in Run base/callback.h:92:12
    #20 0x116e0dbe in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) mojo/public/cpp/system/simple_watcher.cc:276
    #21 0x116e2004 in Invoke<const base::WeakPtr<mojo::SimpleWatcher> &, const int &, const unsigned int &, const mojo::HandleSignalsState &> base/bind_internal.h:194:12
    #22 0x116e2004 in MakeItSo<void (mojo::SimpleWatcher::*const &)(int, unsigned int, const mojo::HandleSignalsState &), const base::WeakPtr<mojo::SimpleWatcher> &, const int &, const unsigned int &, const mojo::HandleSignalsState &> base/bind_internal.h:297
    #23 0x116e2004 in void base::internal::Invoker<base::internal::BindState<void (mojo::SimpleWatcher::*)(int, unsigned int, mojo::HandleSignalsState const&), base::WeakPtr<mojo::SimpleWatcher>, int, unsigned int, mojo::HandleSignalsState>, void ()>::RunImpl<void (mojo::SimpleWatcher::* const&)(int, unsigned int, mojo::HandleSignalsState const&), std::__1::tuple<base::WeakPtr<mojo::SimpleWatcher>, int, unsigned int, mojo::HandleSignalsState> const&, 0ul, 1ul, 2ul, 3ul>(void (mojo::SimpleWatcher::* const&)(int, unsigned int, mojo::HandleSignalsState const&), std::__1::tuple<base::WeakPtr<mojo::SimpleWatcher>, int, unsigned int, mojo::HandleSignalsState> const&, std::__1::integer_sequence<unsigned long, 0ul, 1ul, 2ul, 3ul>) base/bind_internal.h:349
    #24 0xcbab05e in Run base/callback.h:64:12
    #25 0xcbab05e in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) base/debug/task_annotator.cc:57
    #26 0xc3d2b51 in blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(blink::scheduler::internal::WorkQueue*, bool, blink::scheduler::LazyNow, base::TimeTicks*) third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.cc:530:19
    #27 0xc3cb7c0 in blink::scheduler::TaskQueueManager::DoWork(bool) third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.cc:321:13
    #28 0xc3d90d3 in Invoke<const base::WeakPtr<blink::scheduler::TaskQueueManager> &, const bool &> base/bind_internal.h:194:12
    #29 0xc3d90d3 in MakeItSo<void (blink::scheduler::TaskQueueManager::*const &)(bool), const base::WeakPtr<blink::scheduler::TaskQueueManager> &, const bool &> base/bind_internal.h:297
    #30 0xc3d90d3 in void base::internal::Invoker<base::internal::BindState<void (blink::scheduler::TaskQueueManager::*)(bool), base::WeakPtr<blink::scheduler::TaskQueueManager>, bool>, void ()>::RunImpl<void (blink::scheduler::TaskQueueManager::* const&)(bool), std::__1::tuple<base::WeakPtr<blink::scheduler::TaskQueueManager>, bool> const&, 0ul, 1ul>(void (blink::scheduler::TaskQueueManager::* const&)(bool), std::__1::tuple<base::WeakPtr<blink::scheduler::TaskQueueManager>, bool> const&, std::__1::integer_sequence<unsigned long, 0ul, 1ul>) base/bind_internal.h:349
    #31 0xcbab05e in Run base/callback.h:64:12
    #32 0xcbab05e in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) base/debug/task_annotator.cc:57
    #33 0xce2e47e in base::internal::IncomingTaskQueue::RunTask(base::PendingTask*) base/message_loop/incoming_task_queue.cc:130:19
    #34 0xcc26ec1 in base::MessageLoop::RunTask(base::PendingTask*) base/message_loop/message_loop.cc:392:25
    #35 0xcc278ac in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) base/message_loop/message_loop.cc:404:5
    #36 0xcc28243 in base::MessageLoop::DoWork() base/message_loop/message_loop.cc:450:16
    #37 0xcc2cc12 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) base/message_loop/message_pump_default.cc:37:31

SUMMARY: AddressSanitizer: 182000 byte(s) leaked in 1152 allocation(s).
-----------------------------------------------------
Suppressions used:
  count      bytes template
      2        288 libfontconfig
-----------------------------------------------------

[4586:4586:1025/111909.515534:INFO:chrome_cryptauth_service.cc(230)] Refresh token not yet available; waiting before starting CryptAuth managers.
[4586:4586:1025/111909.607351:WARNING:url_request_context_getter.cc(43)] URLRequestContextGetter leaking due to no owning thread.
[4586:4586:1025/111909.607413:WARNING:url_request_context_getter.cc(43)] URLRequestContextGetter leaking due to no owning thread.
[4586:4586:1025/111909.607475:WARNING:url_request_context_getter.cc(43)] URLRequestContextGetter leaking due to no owning thread.

Yeah this stacktrace is so useless :/ Did you try running all tests under lsan to see if maybe something is related to test ordering?

You can ask infra for VNC access to the bot to debug on the actual metal that's hitting the issue.

I tried to reproduce locally by building lsan and the tests pass.
I ran swarming.py to reproduce it shows me 100s of stack traces.
https://pastebin.com/QD8BPMzV
All the stack traces contain blink::DocumentLoader and objects allocated in partition alloc.

Removing Sheriff-Chromium now that the bug is assigned and being investigated.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/46f48d2e35cd23f552b187bc45e6f54ccde71c82

commit 46f48d2e35cd23f552b187bc45e6f54ccde71c82
Author: kylechar <kylechar@chromium.org>
Date: Mon Nov 27 17:13:43 2017

Disable flaky test on CrOS ASan.

MemoryTracingBrowserTest.TestBackgroundMemoryInfra fails frequently on
CrOS ASan trybot. Disable on that trybot until the test is fixed.

Bug:  778405 
Change-Id: Ibab6c54821d0f256a0d60d362663c22ba22b7eaa
Reviewed-on: https://chromium-review.googlesource.com/790552
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519320}
[modify] https://crrev.com/46f48d2e35cd23f552b187bc45e6f54ccde71c82/testing/buildbot/filters/browser_tests_cros_asan.filter

Maybe related: issue 808152, which has a complete stacktrace.