Skip to content

refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook - #2282

Draft
gyuheon0h wants to merge 6 commits into
mainfrom
gyuheon0h/extract-got-hook-crate
Draft

refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook#2282
gyuheon0h wants to merge 6 commits into
mainfrom
gyuheon0h/extract-got-hook-crate

Conversation

@gyuheon0h

@gyuheon0h gyuheon0h commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

The crashtracker needs to hook __assert_fail at runtime using GOT patching. Rather than duplicating ~600 lines of ELF parsing and page-protection code, this extracts the shared primitives into a crate that both libdd-profiling-heap-gotter and libdd-crashtracker can depend on.

What moves to libdd-got-hook

  • ELF types and constants (Elf64_Dyn, DT_*)
  • DynamicInfo::from_phdr -- parse PT_DYNAMIC from a loaded ELF object
  • GNU hash table utilities
  • dl_iterate_phdr wrapper with panic-safe trampoline
  • RELRO-aware page protection management
  • lookup_symbol
  • elf64_r_sym / check_sym — small helpers
  • hook_symbol. This one is new. It is a one-shot single-symbol GOT patcher that wires dlsym, iterate_libraries, and patch_got_entries into a single call

What stays in libdd-profiling-heap-gotter

  • SymbolOverrides; the multi-symbol registry
  • hooks.rs; the actual malloc/free/calloc/realloc hook functions
  • install_heap_overrides / update_heap_overrides public API

What "changed"

  • from_phdr previously returned None when gnu_hash.is_null() but now it falls through to sysv DT_HASH nchain, then the symtab/strtab distance heuristic. This means objects linked with --hash-style=sysv are now parsed instead of skipped. For heap-gotter this is strictly additive more libraries get patched, none get un-patched. This was also a codex recommendation and I am not sure that this is necessary but from what I understand, this does not change behavior for heap prof usage.
  • patch_got_entries and process_relocation now skip relocations that arent GLOB_DAT or JUMP_SLOT. Before, theyd patch any relocation matching symbol name. In practice, all malloc, free, calloc, realloc should be GLOB_DAT/JUMP_SLOT.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

How to test the change?

Describe here in detail how the change can be validated.

gyuheon0h commented Jul 27, 2026

Copy link
Copy Markdown
Contributor Author

@github-actions

github-actions Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 232 documentation warning(s) found

📦 libdd-got-hook - 6 warning(s)

📦 libdd-profiling-heap-gotter - 53 warning(s)

📦 tools - 173 warning(s)


Updated: 2026-07-28 02:38:08 UTC | Commit: ef1944e | missing-docs job results

@github-actions

github-actions Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

⚠️ 3 issue(s) found, showing only errors (advisories, bans, sources)

📦 libdd-got-hook - ✅ No issues

📦 libdd-profiling-heap-gotter - ✅ No issues

📦 tools - 3 error(s)

Show output
error[vulnerability]: Quadratic run time when checking a start tag for duplicate attribute names
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0194
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0194
   ├ `BytesStart::attributes()` returns an `Attributes` iterator which, by default
     (`with_checks(true)`), rejects a start tag that repeats an attribute name. For
     each attribute yielded, the iterator compared the new name against every name
     seen so far in the same tag using a linear scan, so a start tag with `N`
     distinct attribute names cost `O(N²)` byte comparisons. There was no bound on
     `N` other than the size of the buffered start tag.
     
     ## Impact
     
     Any code that parses untrusted XML and iterates a start tag's attributes with
     the default duplicate check enabled can be made to spend CPU time quadratic in
     the number of attributes on a single tag. Because the check is pure computation
     with no `.await`/I/O, an I/O-based timeout on the consumer (for example a read
     or request timeout) cannot interrupt it while it runs.
     
     Measured cost of a single start tag, release build:
     
     | Attributes on one tag | Time |
     |---|---|
     | 80,000  | ~6 s   |
     | 800,000 | ~10 min |
     
     The cost grows with the square of the attribute count, so a start tag of a few
     tens of megabytes can stall a parsing thread for hours. No memory is exhausted
     and the parser does not crash; the effect is CPU exhaustion on the thread doing
     the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
     denying service to that worker. A deployment that places a wall-clock bound on
     parsing, or confines it to a non-critical thread, may consider the availability
     impact lower.
     
     ## Affected code paths
     
     * `BytesStart::attributes()` / `Attributes` iterated with checks enabled (the
       default), and `BytesStart::try_get_attribute`.
     * `NsReader`, which resolves namespaces by iterating a tag's attributes and so
       reaches the same check internally.
     
     Consumers that iterate attributes with `.attributes().with_checks(false)` and do
     not use `NsReader` are not affected.
     
     This was reported as reachable by a remote, unauthenticated attacker in a
     real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
     `snapshot.xml`.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`, where the duplicate check keeps the linear
     scan for start tags with a small number of attributes and switches to an `O(1)`
     hash pre-filter above a threshold, making the whole tag `O(N)`. The reported
     `AttrError::Duplicated` positions are unchanged.
     
     If upgrading is not possible and duplicate-name detection is not required,
     disable it with `.attributes().with_checks(false)` (this does not help
     `NsReader` consumers, which have no equivalent opt-out before 0.41.0).
   ├ Announcement: https://github.com/tafia/quick-xml/issues/969
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v37.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0195
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0195
   ├ `NsReader` resolves namespaces by calling `NamespaceResolver::push` for every
     `Start`/`Empty` event *before* the event is returned to the caller. `push`
     iterated all `xmlns` / `xmlns:*` attributes on the start tag and, for each one,
     appended the prefix bytes to an internal buffer and pushed a `NamespaceBinding`
     (32 bytes on 64-bit) to an internal `Vec`, with no upper bound on the number of
     declarations.
     
     ## Impact
     
     A start tag with `N` namespace declarations drove roughly `3×` the tag's byte
     size in `NamespaceResolver` heap, allocated *inside* `quick-xml` before the
     `NsReader` consumer ever received the event and could inspect or reject it. A
     consumer that bounds its *input* size therefore still cannot bound this
     allocation: an `M`-byte start tag yields on the order of `3 × M` bytes of
     resolver heap the caller never sees.
     
     On untrusted XML this lets a remote, unauthenticated attacker force large heap
     allocations with a single start tag. With several `NsReader`s running
     concurrently on independent inputs (a common server pattern), the allocations
     stack and can exhaust process memory, causing the operating system to kill the
     process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
     Labs Routinator), where concurrent RRDP validation workers parsing a crafted
     `snapshot.xml` exceeded the memory limit and the process was OOM-killed.
     
     ## Affected code paths
     
     Consumers using `NsReader` (which always calls `NamespaceResolver::push` before
     yielding `Start`/`Empty`), or calling `NamespaceResolver::push` directly. A plain
     `Reader` that does not perform namespace resolution is not affected.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`. `NamespaceResolver::push` now rejects a start
     tag that declares more than `DEFAULT_MAX_DECLARATIONS_PER_ELEMENT` (256)
     namespace bindings, returning the new `NamespaceError::TooManyDeclarations`
     instead of allocating without limit. The limit is configurable via
     `NamespaceResolver::set_max_declarations_per_element` (use `usize::MAX` to
     restore the previous unbounded behavior), and `NsReader::resolver_mut()` is
     provided to reach it.
     
     There is no clean workaround for `NsReader` consumers before 0.41.0, as the
     allocation happens inside the reader with no configuration knob to cap it.
   ├ Announcement: https://github.com/tafia/quick-xml/issues/970
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v37.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:75:1
   │
75 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── tools v37.0.0

advisories FAILED, bans ok, sources ok

Updated: 2026-07-28 02:39:43 UTC | Commit: ef1944e | dependency-check job results

@datadog-official

datadog-official Bot commented Jul 27, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 76.17%
Overall Coverage: 74.69% (-0.06%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 67df7e6 | Docs | Datadog PR Page | Give us feedback!

@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 63b2fca to 60c1e60 Compare July 27, 2026 19:14
@gyuheon0h gyuheon0h changed the title refactor: extract shared GOT-patching primitives into libdd-got-hook refatcor(got-patching): extract shared GOT-patching primitives into libdd-got-hook Jul 27, 2026
@gyuheon0h gyuheon0h changed the title refatcor(got-patching): extract shared GOT-patching primitives into libdd-got-hook refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook Jul 27, 2026
@dd-octo-sts

dd-octo-sts Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 87.14 MB 87.14 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.01 MB 8.01 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 98.41 MB 98.41 MB 0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.77 MB 10.77 MB 0% (0 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 26.00 MB 26.00 MB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 89.18 KB 89.18 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 187.96 MB 187.95 MB -0% (-8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 979.41 MB 979.41 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.47 MB 8.47 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 89.18 KB 89.18 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 25.05 MB 25.05 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 49.85 MB 49.85 MB 0% (0 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 22.64 MB 22.64 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 90.58 KB 90.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 192.64 MB 192.62 MB -0% (-16.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 968.48 MB 968.48 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.54 MB 6.54 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 90.58 KB 90.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 26.91 MB 26.91 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 47.44 MB 47.44 MB 0% (0 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 77.73 MB 77.73 MB 0% (0 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 8.91 MB 8.91 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 93.24 MB 93.24 MB 0% (0 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.85 MB 10.85 MB 0% (0 B) 👌

@gyuheon0h
gyuheon0h marked this pull request as ready for review July 27, 2026 20:00
@gyuheon0h
gyuheon0h requested review from a team as code owners July 27, 2026 20:00
Move the ELF parsing, dl_iterate_phdr iteration, PageProtGuard,
gnu_hash_symbol_count, gnu_hash_lookup, lookup_symbol, and
hook_symbol utilities out of libdd-profiling-heap-gotter into a
new libdd-got-hook crate.

libdd-profiling-heap-gotter now depends on libdd-got-hook and keeps
only the SymbolOverrides multi-symbol registry and per-library
dedup/rescan logic.

Also adds DT_HASH (sysv) fallback for determining dynsym entry
count, so objects linked with --hash-style=sysv are no longer
silently skipped.
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 822405c to 6ab7768 Compare July 27, 2026 20:01

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 822405c2e5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread libdd-got-hook/src/elf.rs Outdated
Comment thread libdd-got-hook/src/elf.rs
Comment on lines +683 to +687
let sym_idx = elf64_r_sym(reloc.r_info) as u32;
if let Some(cstr) = dyn_info.sym_name(sym_idx) {
if cstr.to_bytes() == symbol_name {
let addr = reloc.r_offset as usize + dyn_info.base_address;
if guard.override_entry(addr, hook_fn) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Filter relocations before writing pointer-sized values

When a loaded object has a symbol-matching dynamic relocation that is not a GOT pointer relocation—for example a legacy R_X86_64_PC32 text relocation—this loop still treats r_offset as an eight-byte pointer slot. override_entry then overwrites eight bytes even though that relocation's field is only four bytes and has different semantics, corrupting adjacent code or data. Inspect the architecture-specific relocation type from r_info and patch only supported pointer-slot types such as GLOB_DAT and JUMP_SLOT (or handle every accepted type according to its width and addend semantics).

Useful? React with 👍 / 👎.

Comment thread libdd-got-hook/src/elf.rs
Comment on lines +616 to +622
let mut patched_any = false;
let mut guard = PageProtGuard::new();

let guard_ptr = &mut guard as *mut PageProtGuard;
let patched_ptr = &mut patched_any as *mut bool;

iterate_libraries(|info, _is_exe| {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Serialize page-protection patching passes

When two threads invoke hook_symbol concurrently—or this function overlaps with the heap gotter's patching pass—each creates an independent PageProtGuard and changes the same GOT page protections without synchronization. One guard can restore the page to read-only while the other is still writing, causing a fault, while a guard that observed the temporary RW mapping can instead restore RW and permanently weaken RELRO. Serialize all patching passes with a process-wide lock, or make non-overlap an explicit enforced safety precondition.

Useful? React with 👍 / 👎.

@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 6ab7768 to 285cdd3 Compare July 27, 2026 20:06
@pr-commenter

pr-commenter Bot commented Jul 27, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-07-28 03:08:31

Comparing candidate commit 67df7e6 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit f2010b6 in branch main.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 141 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:otlp/e2e_protobuf/1x1000

  • 🟥 execution_time [+187.556µs; +189.597µs] or [+5.444%; +5.503%]

Benchmark execution time: 2026-07-28 03:26:09

Comparing candidate commit 67df7e6 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit f2010b6 in branch main.

Found 4 performance improvements and 8 performance regressions! Performance is the same for 165 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:alloc_free/sampled_noop_fast_path/16

  • 🟥 execution_time [+2.810ns; +2.817ns] or [+19.419%; +19.461%]

scenario:alloc_free/sampled_noop_fast_path/256

  • 🟥 execution_time [+2.809ns; +2.816ns] or [+19.410%; +19.458%]

scenario:alloc_free/sampled_noop_fast_path/4096

  • 🟥 execution_time [+2.811ns; +2.817ns] or [+19.423%; +19.463%]

scenario:alloc_free/sampled_noop_fast_path/64

  • 🟥 execution_time [+2.811ns; +2.817ns] or [+19.425%; +19.466%]

scenario:alloc_free/sampled_noop_fast_path/65536

  • 🟥 execution_time [+2.811ns; +2.817ns] or [+19.424%; +19.467%]

scenario:alloc_free/sampled_system_fast_path/4096

  • 🟥 execution_time [+11.593ns; +11.739ns] or [+12.560%; +12.717%]

scenario:alloc_free/system/4096

  • 🟥 execution_time [+26.142ns; +26.254ns] or [+32.732%; +32.873%]

scenario:datadog_sample_span/complex_rule_partial_match/wall_time

  • 🟩 execution_time [-12.929ns; -12.266ns] or [-5.204%; -4.938%]

scenario:receiver_entry_point/report/2644

  • 🟥 execution_time [+178.164µs; +186.560µs] or [+4.885%; +5.115%]

scenario:tags/replace_trace_tags

  • 🟩 execution_time [-128.504ns; -121.519ns] or [-5.177%; -4.896%]

scenario:trace_buffer/4_senders/no_delay

  • 🟩 execution_time [-152.130µs; -117.324µs] or [-6.491%; -5.006%]
  • 🟩 throughput [+83122.453op/s; +108106.278op/s] or [+5.406%; +7.031%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@gyuheon0h
gyuheon0h marked this pull request as draft July 27, 2026 21:07
@gyuheon0h
gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 978bf00 to 67df7e6 Compare July 28, 2026 02:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant