fix(liveness): release jweak ref when liveness table overflows or realloc fails#556
Conversation
…lloc fails PROF-14823 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
CI Test ResultsRun: #26620665645 | Commit:
Status Overview
Legend: ✅ passed | ❌ failed | ⚪ skipped | 🚫 cancelled Summary: Total: 32 | Passed: 32 | Failed: 0 Updated: 2026-05-29 06:30:58 UTC |
|
…alloc failure Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be3fe3bb21
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Fixes jweak leaks in LivenessTracker::track() when an allocation can’t be added to the liveness tracking table, ensuring weak refs are properly released on failure/overflow paths.
Changes:
- Call
DeleteWeakGlobalRefwhen the tracking table is at max capacity and cannot accept the new entry. - Call
DeleteWeakGlobalRefon the post-retry overflow path (e.g., after a failed resize attempt / still full after cleanup), preventing a droppedjweakfrom leaking.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
What does this PR do?:
Fixes three
jweakreference leaks inLivenessTracker::track()when the tracking table cannot accept a new entry.Motivation:
Some leftovers with potential of memory leaks in critical conditions.
Additional Notes:
Three paths in
livenessTracker.cppdropped the JNI weak global ref without callingDeleteWeakGlobalRef:reallocfailure: when resizing failed, the code fell through togoto retrysocleanup_table's freed slots could still be used. If the retry also failed (retried==true,idx==_table_cap), the ref was silently dropped. Fixed by adding anelse { DeleteWeakGlobalRef(ref); }on theretried==truepath that handles final-failure cleanup.Table at max capacity (initial pass): the ref was silently dropped when
_table_cap == _table_max_cap. Now deleted before exiting.Table still full after resize retry (
retried==true): concurrent threads can re-fill all newly-allocated slots before the retrying thread wins the CAS. This path had no cleanup. Fixed by the sameelse { DeleteWeakGlobalRef(ref); }added for case 1.How to test the change?:
Code inspection — the three affected paths are straightforward error exits that previously had no
DeleteWeakGlobalRefcall.credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance.