Hello Adar Dembo,
I'd like you to do a code review. Please visit
http://gerrit.cloudera.org:8080/6791
to review the following change.
Change subject: WIP: KUDU-1992. striped64: don't heap-allocate the threadlocal
hashcode
......................................................................
WIP: KUDU-1992. striped64: don't heap-allocate the threadlocal hashcode
KUDU-1992 describes a bug in which the destructor of one threadlocal
object ended up referring to another threadlocal object. Specifically, a
threadlocal cached block destructor ended up incrementing a metric which
was implemented by a LongAdder (inheriting from Striped64). The
LongAdder uses a threadlocal hashcode to avoid contention.
In the crash described in the bug, the striped64's TLS hashcode was
destructed before the other destructor ran, causing a
heap-use-after-free.
This patch should fix the issue by making the threadlocal hashcode be a
POD threadlocal rather than a pointer to a heap-allocated object. Thus
there is no destructor to run, and no chance that the destruction order
can cause this crash.
This fix seemed simpler than trying to ensure some specific ordering of
threadlocal destructors (eg by assigning destructor priorities or adding
some kind of dependency graph).
WIP because I would like to run a dist-test loop to ensure it's really
fixed.
Change-Id: I2d4e5264134c70ced434c3ae8da5866a151464d5
---
M src/kudu/util/striped64.cc
M src/kudu/util/striped64.h
2 files changed, 19 insertions(+), 24 deletions(-)
git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/91/6791/1
--
To view, visit http://gerrit.cloudera.org:8080/6791
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I2d4e5264134c70ced434c3ae8da5866a151464d5
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <[email protected]>
Gerrit-Reviewer: Adar Dembo <[email protected]>
