| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
CI Test ResultsRun: #37610327351 | Commit: f5a97ff | Duration: 17m 33s (longest job)
Status Overview
Legend: ✅ passed | ❌ failed | ⚪ skipped | 🚫 cancelled Summary: Total: 76 | Passed: 76 | Failed: 0 Updated: 2026-10-07 11:13:19 UTC |
Sorry, something went wrong.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Sorry, something went wrong.
|
@rkennke Not sure if these changes are not redoing some things from your currently open PRs, let's wait until they are merged to see if this still makes sense. |
Sorry, something went wrong.
There was a problem hiding this comment.
Here are some automated review suggestions for this pull request.
Reviewed commit: fbfa879569
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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".
Sorry, something went wrong.
There was a problem hiding this comment.
The retained first counter-firing dump can contain the stale frame only in datadog.ObjectSample, but the assertion ignores that event type, so the nightly stress test can still fail even when the intended <unloaded> label was emitted.
🤖 Bits Code Review · Commit fbfa879 · @DataDog review to ask questions
Sorry, something went wrong.
| // With skippedDelta > 0, firedDumpFile is always set: either the dump whose window | ||
| // observed the counter crossing (label emitted in that same fillJavaMethodInfo call) | ||
| // or the extra post-churn dump taken above. | ||
| assertUnloadedFrameLabel(firedDumpFile); |
There was a problem hiding this comment.
Inspect ObjectSample in the selected snapshot
When the first counter increase comes from an allocation trace, the retained dump may contain the stale frame only in datadog.ObjectSample. The assertion instead scans nonexistent datadog.AllocationSample, causing a false failure even though the expected <unloaded> label was emitted.
Was this helpful? React 👍 or 👎
🤖 Bits Code Review · @DataDog review to ask questions · Open Bits AI session
Sorry, something went wrong.
There was a problem hiding this comment.
looks good to me; thanks for the fix!
Sorry, something went wrong.
…d_count The counter delta spans the whole churn window (dumps and background JFR flushes) while the label assertion read only the last dump file; a stale trace can be evicted from the call-trace storage before the final dump, making the test flaky across JDKs/platforms. Snapshot the dump whose window observed the counter crossing and assert on it; if the counter only fired between dumps, take one more dump before stop.
| Back | FazBrowse Home | New Git URL |
What does this PR do?:
Fixes the three failure classes recurring in the Nightly Sanitized Run (e.g. https://github.com/DataDog/java-profiler/actions/runs/36663570752):
UBSan: applying non-zero offset to null pointer — attributionPC() (stackWalker.inline.h) does (char*)pc - 1 for return-address pcs. An optimistic unwind can read a zeroed return-address slot, so pc == nullptr with pc_is_return_address == true reaches it, UBSan (asan config) reports the error and the test JVM exits 1, killing every run-slow-test-asan job. Fix: pass a null pc through unchanged (behavior-identical to pre-PROF-15955 walkers — findLibraryByAddress(nullptr) fails either way).
Fuzz harness no longer compiles — 9010c4c3a switched CallTraceSet to CountingAllocator, but the fuzz_callTraceStorage.cpp lambda still declared const std::unordered_set<CallTrace*>& (default allocator), which is not convertible to std::function<void(const CallTraceSet&)>. compileFuzz_callTraceStorage has failed every nightly since. Fix: use const CallTraceSet&.
JMethodIDInvalidationStressTest flake (graal/musl/glibc, JDK 21/25) — jmethodid_skipped_count accumulates over the whole churn window (dumps and background JFR flushes), but the <unloaded> label assertion read only the last dump file; the stale trace can be evicted from the call-trace storage before the final dump. Fix: snapshot the dump whose counter window fired (the increment and the <unloaded> label are emitted in the same fillJavaMethodInfo call, so that recording is guaranteed to carry the label); if the counter only fired between dumps, take one extra dump before stop().
The cache-jdks / cache-amd64-musl failure in the same run is an Alpine CDN TLS infra flake, untouched.
Motivation:
Nightly Sanitized Run failing regularly for the last few weeks, masking real regressions. The fuzz failure also showed that a job failure can coexist with a run-level "success" conclusion, so per-job status is the reliable signal.
Additional Notes:
How to test the change?:
For Datadog employees:
credentials of any kind, I've requested a security review (run the dd:platform-security-review
skill, or file a request via the PSEC review form).
bewaire also runs automatically on every PR.