Fix stack-walking race

During stack walking it was possible for a walking thread to race with
the InstrumentationInstallStack. In this case the stack changes made
by InstrumentationInstallStack could cause the other thread to
incorrectly parse the stack data-structures, leading to
failures/crashes.

To fix this we increment an ID whenever instrumentation changes the
instrumentation stack. Other stack-walkers then check this id and
restart whenever it changes. Note that although the stack-walk
restarts we keep track of how many java frames we've visited already
and refrain from calling VisitFrame until we are at the same position
again. This means that as far as the Visitor writers are concerned the
stack-walk is only done once, just like always.

Added a test (2011) that forces the race to occur.

Also Disabled Dex2oatSwapUseTest#CheckSwapUsage. It seems that the
increase in Thread* size has caused it to fail. Disable while we
investigate. See b/29259363

Bug: 72608560
Bug: 29259363
Bug: 148166031
Test: ./test.py --host
Test: ./test/run-test --host --dev --runtime-option -verbose:deopt,plugin --prebuild --compact-dex-level fast --jit --no-relocate --create-runner --runtime-option -Xcheck:jni 1965-get-set-local-primitive-no-tables
      parallel_run.py
Change-Id: I77349dfc6fa860b7f007dee485e9fea1d8658090

0 files changed, 0 insertions, 0 deletions