-
Notifications
You must be signed in to change notification settings - Fork 9
Properly manage JNI resources in JVMTI wallclock sampler #168
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 Scan-Build Report
Bug Summary
Reports
|
Thanks for figuring things out! I'll try to run things to see how it behaves. |
027351d
to
61248da
Compare
61248da
to
522c37e
Compare
I have found some weird behaviour in JVMTI, especially when I try using RAII objects. |
JVMTI GetAllThreads() is buggy - it will retain strong references to all returned threads until the particular JVTMI environment is shut down. This effectively means a nasty thread leak when calling |
What does this PR do?:
It fixes the issue with the JVMTI wallclock sampler keep all threads in the system alive indefinitely
Motivation:
Resolve the corresponding memory leak. Make JVMTI wallclock sampler usable.
Additional Notes:
Due to stricter checks for thread state before collecting stacktrace and proper resource management, the #167 is not necessary any more.
How to test the change?:
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!