-
Notifications
You must be signed in to change notification settings - Fork 9
Potential memory leak and race with the JVMTI wallclock sampler #234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🔧 Report generated by pr-comment-scanbuild |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
jint threads_count = 0; | ||
jthread* threads_ptr = nullptr; | ||
if (jvmti->GetAllThreads(&threads_count, &threads_ptr) != JVMTI_ERROR_NONE || | ||
threads_count == 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not my domain, though I think returning on threads_count == 0 is a functional difference.
I think it is OK to stop the profiler if there are no threads.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we should always have at least one thread reported by JVMTI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I allowed myself to pull |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a few things I think are not right. Please, re-check and eventually fix. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
* Split debug Add build steps to store split debug information for release builds
* Add the micro-benchmark for thread filtering * Do not test for obviously invalid thread id * Relax threadfilter mem order
Skip zing and j9 flaky tests
Lower threshold for allocation test
2e7e43f
to
a1db674
Compare
What does this PR do?:
Release
jthread
local reference to prevent memory leak.Profiler uses
jvmtiError GetAllThreads(jvmtiEnv* env, jint* threads_count_ptr, jthread** threads_ptr)
to obtain a list of running threads. The document statesThe returned array contains JNI local references of threads, should be managed by caller, which means the caller should manage the life cycle of returned JNI local reference. In this case, we should delete those JNI local references to avoid the leak.
Also, JVMTI
GetAllTheads()
snapshots alive threads, the returned JNI local references only guarantee thatThread
objects are not reclaimed by GCs, it does not prevent underneath native thread from exiting, so that, we have to be extremely careful when examining captured thread's native structures, as they may no longer be valid.Motivation:
Make JVMTI wallclock sampler useable.
Additional Notes:
How to test the change?:
Run:
It crashes without this fix, no crash with the fix.
For Datadog employees:
credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance
.Unsure? Have a question? Request a review!