New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 680042 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Jan 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Data race in base::internal::BindState<void

Project Member Reported by ClusterFuzz, Jan 11 2017

Issue description

Cc: msrchandra@chromium.org
Labels: Test-Predator-Wrong-CLs
Owner: csharrison@chromium.org
Status: Assigned (was: Untriaged)
Find it and CL did not provide any possible suspects.
Using Code Search for the file, "StringImpl.h" assigning to the concern owner.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/36ecc9ec6ab699d9300f50fd4ca26030acad3e26

@csharrison -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.
Project Member

Comment 2 by bugdroid1@chromium.org, Jan 11 2017

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

commit 9b559c6994582ca25952810057dc778e82685ede
Author: csharrison <csharrison@chromium.org>
Date: Wed Jan 11 22:46:45 2017

Make WebTaskRunner::postTask thread safe

Copying the summary from dcheng@ on the referenced bug:

The current implementation looks like this:
void WebTaskRunner::postTask(const WebTraceLocation& location,
                             std::unique_ptr<CrossThreadClosure> task) {
  toSingleThreadTaskRunner()->PostTask(location,

     convertToBaseCallback(std::move(task)));
}

However, base::TaskRunner::PostTask() takes a const base::Closure&.
When we convert the CrossThreadClosure to a base::Callback, we just
extract the internal callback object. However, this callback object is
never supposed to be copied, only moved.

Since the base APIs haven't been updated to use base::OnceCallback, now
 we have two copies of the callback referencing the same
base::BindState (which is holding the bound variables): one on the
posting thread (call it thread 1), and one on the posted thread (call
it thread 2).

If the copy on thread 2 is destroyed before the copy on thread 1,
base::BindState will be destroyed on thread 1. If base::BindState
contained WTF::String or other thread-unsafe objects, and thread 2
copied it, this means that the thread-unsafe objects will be ref'ed
and deref'ed on multiple threads, which is not good.

BUG= 679915 ,  680042 

Review-Url: https://codereview.chromium.org/2626883003
Cr-Commit-Position: refs/heads/master@{#443028}

[modify] https://crrev.com/9b559c6994582ca25952810057dc778e82685ede/third_party/WebKit/Source/platform/WebTaskRunner.cpp

Project Member

Comment 3 by ClusterFuzz, Jan 13 2017

ClusterFuzz has detected this issue as fixed in range 442831:443258.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6629240285167616

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 8
Crash Address: 0x7b100005db90
Crash State:
  base::internal::BindState<void
  base::internal::CallbackBase<
  blink::WebTaskRunner::postTask
  
Sanitizer: thread (TSAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=435605:436997
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=442831:443258

Minimized Testcase (6.53 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95covJ-3TvFetn9Te1QsyKWKjLOR7M-pz6PMhBGm2h2rcC3FsejpjMjav5kglB_deALGoPF2I2RgfJ1MI2O8wO33q_UYdJ1roOkEmhV1ga_lTrK3CRXvRJGJHHgIkUtqZvWvw_nYBlfADB-l7xplDimJONJe5pKVnMZXaX2iQREXBU1S2Auez1_Y2FP3n-pbt-xURlXId8uyMYbeX3dvXU8Ex7geuOKyYjqmMw9AbqO9cqjBELX-puf7afJDPycgYNmEiCh9THHD2cHRyOu9gyFX2JbjxGcy8Mcxwyd8rBPk6_5E0OH2K_YQs8zPOPlqA_KTwEkn4xlhMOJ_WVlXAeMOgUXUY30C5A_SVxFL9VYTjFFtXFzOyvP-cuikeEt5mK3uvTQSp2C0pqYx585jNp3t76bIA?testcase_id=6629240285167616

Additional requirements: Requires Gestures

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
Project Member

Comment 4 by ClusterFuzz, Jan 13 2017

Labels: ClusterFuzz-Verified
Status: Verified (was: Assigned)
ClusterFuzz testcase 6629240285167616 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Sign in to add a comment