The two AssociatedGroupController implementations we have both own a lock
which is acquired during message dispatch, among other operations.
In the EDK layer a Watcher lock is also acquired further up the stack.
Because sending a message may indirectly require notifying the same
Watcher lock, it must never be true that the AssociatedGroupController's
lock is held while its pipe is written to.
This fixes the lock-order inversion resulting from the
fact that pipe control messages were being sent under lock, and removes
the associated TSAN suppression.
BUG=663557
TBR=glider@chromium.orgR=yzshen@chromium.org
Review-Url: https://codereview.chromium.org/2494483003
Cr-Original-Commit-Position: refs/heads/master@{#431331}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 58909542197b704efe10526c169e4b502f799b57
This CL destructs base::Thread and its underlying system thread before
WorkerThread::terminateAndWait returns. This is important to make sure that
the main thread calls WTF::shutdown() after ThreadSpecifics of all threads
are destructed. See 345240 for more details.
BUG=345240
Review-Url: https://codereview.chromium.org/2251903002
Cr-Original-Commit-Position: refs/heads/master@{#412735}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 30d88091658428a57d4567d72f41a8a251031f68
The race condition is expected as we're racing the thread reclaim
logic. ThreadLocalStorage happens to not synchronize anything at the
moment. Adding a lock to synchronize usage of g_tls_destructors won't
actually fix the inherent race condition. In production, it's up the
owner to make sure that any references have cleaned up before
releasing the TLS slot.
Given that ThreadLocalStorage will be getting some locks in the future,
so I expect to be able to remove the suppression once that goes
through.
BUG=638378
Review-Url: https://codereview.chromium.org/2256493002
Cr-Original-Commit-Position: refs/heads/master@{#412362}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ad1893a4eeeb1775709005ad7df0081560fa27d3
The compiler does not include the class name in the symbol name for the
TestBody method so the suppression added in r409915 doesn't work. This
patch disables the test under TSan instead.
BUG=634383,629716
TBR=thestig@chromium.org
NOTRY=true
Review-Url: https://codereview.chromium.org/2218663003
Cr-Original-Commit-Position: refs/heads/master@{#410159}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4ef71eefd26cd7c4f3ee5c7d4fbff9aaed2a5459
All the LKGR clusterfuzz bots build this target, so add it to allow
switching these bots to gn.
BUG=618702,542853,619086
TBR=eroman
Review-Url: https://codereview.chromium.org/2059843002
Cr-Original-Commit-Position: refs/heads/master@{#399241}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3f7d4fc75b62ca7008642c5aea6233eade695da5
CSSValuePool was used to be static instance on main thread
only. But OffscreenCanvas in a worker requires to access
the CSS value caches in a non-main thread. This patch uses
the ThreadSpecific persistent handles to create static
CSSValuePool instances per thread when needed, and the
cleanup code is handled in ThreadState::cleanup() added by
patch https://codereview.chromium.org/1881933005.
As a result, WebKit unit tests (which does not use the
ThreadState::cleanup() as the worker thread) need to be
modified so that false positive leak errors will not be
reported.
In addition, an indirect memory leak "__strdup
/build/eglibc-3GlaMS/eglibc-2.19/string/strdup.c" is
generated in webkit unit tests; but after printing out the
full error stack trace, we observe that it eventually
originates from libfontconfig, a third_party library that
has leaks and has already been suppressed in
leak_suppression.cc. But the default stack trace is too
short on suppress this indirect memory leak; so we added
one more leak suppression underneath the libfontconfig.
BUG=599659
Review URL: https://codereview.chromium.org/1870503002
Cr-Original-Commit-Position: refs/heads/master@{#388815}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1174eb6ddb160985b51d1d45321e24c493aa7f83
The move to libvpx_new happened before M47 (landed in 2524, M47 branch was 2526):
crbug.com/481034
https://codereview.chromium.org/1323333002
Clients which try to transition directly between the tree after this change and before the previous move will end up in a very broken state.
Now it is 6 months later and M48 is stable so is unlikely that a client would check out the old code at all, much less try to transition directly between the two versions.
Leave a compatibility layer for targets which need to be updated out of band (webrtc, libyuv)
Review URL: https://codereview.chromium.org/1734613003
Cr-Original-Commit-Position: refs/heads/master@{#378739}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8cdf034791388299f18fba186f2941313320b706
The difference with this re-land is that it changes LazyInstance to be leaky to avoid a recursive lock acquisition in AtExitManager. It also doesn't make sense to destroy that instance since it's a cache of a command line flag.
BUG=539315
Review URL: https://codereview.chromium.org/1646223002
Cr-Commit-Position: refs/heads/master@{#372501}
Review URL: https://codereview.chromium.org/1663693002
Cr-Original-Commit-Position: refs/heads/master@{#373176}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6be610508ebbc1787e959e741861f6eecff02c8d
This change fixes two different races:
1. On destruction of BrowserThreadImpl, the thread is removed from the global
thread table after it is stopped. The process of stopping the thread destroys
the thread's message loop. However, PostTaskHelper accesses the message loop,
which races with the stopping thread. Reordering the two operations is not
sufficient because it doesn't handle subclasses (i.e. BrowserProcessSubThread)
stopping the thread.
2. There's a missing lock in GetCurrentThreadIdentifier when accessing the
global thread table. To track whether or not this causes lock contention, a
ScopedTracker has been added.
The two other changes are:
1. Remove uses of ScopedAllowSingleton. This isn't necessary any more since the
relevant objects are leaky.
2. Remove impossible cases in BrowserThreadImpl::Run().
BUG=115540
Review URL: https://codereview.chromium.org/1564193002
Cr-Original-Commit-Position: refs/heads/master@{#370560}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 83e3480a731d95a97ccc1eacd7b3356ded42b0d4
This also addresses a harmless read of uninitialized 2-bytes to quiet the Valgrind error. Also it adds a lock around the usage of initialized_ in RawChannel, even though it's not needed since it's just an optimization to avoid thread hops.
BUG=561803,571735
TBR=glider, thakis
Review URL: https://codereview.chromium.org/1549703002
Cr-Original-Commit-Position: refs/heads/master@{#366727}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9269e9ad8cb31a90e0ecfa0b24a597776d962d5d
The MessageLoopHelper 'helper' is created on the main thread in this test, so to
avoid a race condition move invocation of helper.CallbackCalled() from
CacheThread to the main thread.
BUG=313726
Review URL: https://codereview.chromium.org/1460053003
Cr-Original-Commit-Position: refs/heads/master@{#362429}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 07477ffeefe3587f8d91b36d388e7fb73dc4d8da
This makes it possible to test GLImage implementations without
requiring multi-process GpuMemoryBuffer support.
This initial version is limited to testing CopyTexSubImage with
the default buffer format but testing of more functionality and
formats will be added in follow up patches.
Also includes some minor cleanup needed to not have GLImage
implementations depend on GpuMemoryBuffer API.
BUG=538325
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1354483004
Cr-Original-Commit-Position: refs/heads/master@{#353735}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8aa0fb1d78963610ab62a349d1dff9bd2e065a3e