It appears death tests might cause thread
termination problems (omitting sanity checks): 
tools/valgrind/chrome_tests.sh --tool memcheck --build-dir /chromium_asan/src/out/Release -t base_unittests --gtest_filter=AllocationRegister*Overflow*:Wo*

Reliably reproduces the leak:
[==========] Running 2 tests from 2 test cases.
[----------] Global test environment set-up.
[----------] 1 test from WorkerPoolTest
[ RUN      ] WorkerPoolTest.PostTask
[       OK ] WorkerPoolTest.PostTask (187 ms)
[----------] 1 test from WorkerPoolTest (214 ms total)

[----------] 1 test from AllocationRegisterTest
[ RUN      ] AllocationRegisterTest.OverflowDeathTest

[WARNING] ../../testing/gtest/src/gtest-death-test.cc:834:: Death tests use
fork(), which is unsafe particularly in a threaded context. For this test,
Google Test detected 3 threads.
[       OK ] AllocationRegisterTest.OverflowDeathTest (230 ms)
[----------] 1 test from AllocationRegisterTest (230 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 2 test cases ran. (485 ms total)
[  PASSED  ] 2 tests.

Leak_DefinitelyLost
2,048 bytes in 1 blocks are definitely lost in loss record 9,742 of 9,752
  operator new[](unsigned long) (m_replacemalloc/vg_replace_malloc.c:1144)
  (anonymous namespace)::ConstructTlsVector()
(base/threading/thread_local_storage.cc:107)
  base::ThreadLocalStorage::StaticSlot::Set(void*)
(base/threading/thread_local_storage.cc:246)
  base::ThreadLocalPointer<void>::Set(void*) (base/threading/thread_local.h:69)
  base::ThreadLocalBoolean::Set(bool) (base/threading/thread_local.h:88)
  base::(anonymous namespace)::WorkerThread::ThreadMain()
(base/threading/worker_pool_posix.cc:79)
  base::(anonymous namespace)::ThreadFunc(void*)
(base/threading/platform_thread_posix.cc:68)
Suppression (error hash=#F6EC67ECF9CF9B28#):
  For more info on using suppressions see
http://dev.chromium.org/developers/tree-sheriffs/sheriff-details-chromium/mem...
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:_Zna*
   fun:_ZN12_GLOBAL__N_118ConstructTlsVectorEv
   fun:_ZN4base18ThreadLocalStorage10StaticSlot3SetEPv
   fun:_ZN4base18ThreadLocalPointerIvE3SetEPv
   fun:_ZN4base18ThreadLocalBoolean3SetEb
   fun:_ZN4base12_GLOBAL__N_112WorkerThread10ThreadMainEv
   fun:_ZN4base12_GLOBAL__N_110ThreadFuncEPv
}


unit_tests also encounter a similar leak
Leak_DefinitelyLost
8,192 bytes in 4 blocks are definitely lost in loss record 40,719 of 40,770
  operator new[](unsigned long) (m_replacemalloc/vg_replace_malloc.c:1144)
  (anonymous namespace)::ConstructTlsVector() (base/threading/thread_local_storage.cc:107)
  base::ThreadLocalStorage::StaticSlot::Set(void*) (base/threading/thread_local_storage.cc:246)
  base::ThreadLocalPointer<void>::Set(void*) (base/threading/thread_local.h:69)
50 new files were left in /tmp: Fix the tests to clean up themselves.
  base::ThreadLocalBoolean::Set(bool) (base/threading/thread_local.h:88)
  base::(anonymous namespace)::WorkerThread::ThreadMain() (base/threading/worker_pool_posix.cc:79)
  base::(anonymous namespace)::ThreadFunc(void*) (base/threading/platform_thread_posix.cc:68)
Suppression (error hash=#F6EC67ECF9CF9B28#):
  For more info on using suppressions see http://dev.chromium.org/developers/tree-sheriffs/sheriff-details-chromium/memory-sheriff#TOC-Suppressing-memory-reports
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:_Zna*
   fun:_ZN12_GLOBAL__N_118ConstructTlsVectorEv
   fun:_ZN4base18ThreadLocalStorage10StaticSlot3SetEPv
   fun:_ZN4base18ThreadLocalPointerIvE3SetEPv
   fun:_ZN4base18ThreadLocalBoolean3SetEb
   fun:_ZN4base12_GLOBAL__N_112WorkerThread10ThreadMainEv
   fun:_ZN4base12_GLOBAL__N_110ThreadFuncEPv
}

The unit_tests investigation is ongoing.