Add sanity tests for various idling/blocking operations #1179
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This adds two additional tests based on what we have in Datadog Java Profiler.
Motivation and context
These tests will reliably fail on AARCH64 when running on JDK 8/11 from Temurin or Liberica distribution. On other distributions (Corretto and Zulu - other don't seem to provide up-to-date updates of 8 and 11 so, hopefully, their usage will be phased out) the tests are passing just fine.
The main issue seems to be related to somehow mangled FP/LR when calling to some JIT compiled methods (most frequently this fails for things like 'Thread.sleep()
orObject.wait()`) where following the standard rules for obtaining FP and LR as SP[-8] and SP[-16] yield bogus values.The exact location is here - https://github.com/DataDog/async-profiler/blob/f71c31af7b6972fc5432d0be33ed75a34ab3f710/src/stackWalker.cpp#L292
I checked the instructions for the affected methods and the frame size is correct, so the FP and LR values already arrive mangled.
I have a very experimental and WIP code in branch where I am trying to wrap my head around what and how is actually mangling the linkage.
A desperate attempt is to use the standard FP walking to recover in such situation - and, to my surprise, it mostly works. Well, if paired with opportunistic recovery from the thread JavaFrameAnchor (if there is any). But still it can create broken or 'surprising' stacktraces
I want to add these three tests (well, two tests and one extra configuration of the existing test) to allow perhaps someone more knowledgeable in ways how different toolchain/compilation might mangle FP/LR such that they are not directly usable from a compiled method.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.