feat(crashtracking)!: read crashing thread context by gyuheon0h · Pull Request #2761 · DataDog/libdatadog

gyuheon0h · 2026-10-29T15:26:27Z

What does this PR do?

Add OTel thread context collection to the crashtracker. When a process crashes, the collector reads each thread's otel_thread_ctx_v1 TLS record, containing trace ID, span ID, trace flags, and packed attributes, and includes them in the crash report under experimental.otel_thread_contexts. This lets crash reports carry the OpenTelemetry context that was active on each thread at the time of the crash, enabling correlation with distributed traces even when telemetry pipelines are unavailable.

The collector forks a child process that ptraces each parent thread while it is stopped. For each thread it walks the
Dynamic Thread Vector through /proc/<pid>/mem to resolve the thread's TLS slot address, using the module ID and offset discovered with dl_iterate_phdr, which works correctly for both static TLS (linked at load time) and dynamic TLS (dlopen'd after threads exist). It then does a read of the record (28-byte header first, then only the attrs_data_size attribute bytes) to avoid reading past the allocation, and emits the raw bytes over the pipe to the receiver, which decodes them into structured OtelThreadContext entries in the crash report JSON. The feature is gated behind the otel-thread-ctx cargo feature (default-on) and the collect_otel_thread_contexts runtime config flag.

I did temporary integration tests verify the full fork + ptrace + DTV walk flow for both static and dynamic TLS scenarios.

=== Static TLS (fork + ptrace) ===
--- fork_ptrace_test (static TLS) ---
child: modid=1, offset=32, threads=4
PASS [tid=3639211]: matched worker-a, trace_id=11111111111111111111111111111111
PASS [tid=3639212]: matched worker-b, trace_id=22222222222222222222222222222222
PASS [tid=3639213]: matched worker-c, trace_id=33333333333333333333333333333333

>>> Static TLS (fork + ptrace): OK

=== Dynamic TLS via dlopen (fork + ptrace) ===
--- dlopen_test (dynamic TLS, fork+ptrace) ---
modid=3, offset=4128
child: modid=3, offset=4128, threads=5
PASS [tid=3639217]: matched worker-0, trace_id=11111111111111111111111111111111
PASS [tid=3639218]: matched worker-1, trace_id=22222222222222222222222222222222
PASS [tid=3639219]: matched worker-2, trace_id=33333333333333333333333333333333
PASS [tid=3639220]: matched worker-3, trace_id=44444444444444444444444444444444

>>> Dynamic TLS via dlopen (fork + ptrace): OK

========================================
Results: 2 passed, 0 failed
========================================

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 · 2026-10-29T15:26:41Z

feat(crashtracking)!: read crashing thread context #2761 👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

github-actions · 2026-10-29T15:28:51Z

📚 Documentation Check Results

⚠️ 3230 documentation warning(s) found

📦 `bin_tests` - 1097 warning(s)

📦 `libdd-crashtracker-ffi` - 1152 warning(s)

📦 `libdd-crashtracker` - 980 warning(s)

📦 `libdd-otel-thread-ctx` - 1 warning(s)

Updated: 2026-11-09 20:33:16 UTC | Commit: 1a37f0f | missing-docs job results

github-actions · 2026-10-29T15:30:26Z

🔒 Cargo Deny Results

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

📦 `bin_tests` - 5 error(s)

Show output

info: syncing channel updates for 1.91.1-x86_64-unknown-linux-gnu
info: latest update on 2025-11-10 for version 1.91.1 (ed61e7d7e 2025-11-07)
info: downloading 6 components
warn: the missing active toolchain `1.91.1-x86_64-unknown-linux-gnu` has been auto-installed
warn: this might cause rustup commands to take longer time to finish than expected
info: you may opt out with `RUSTUP_AUTO_INSTALL=0` or `rustup set auto-install disable`
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:240:1
    │
240 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/pull/3265
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── bin_tests v0.1.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── bin_tests v0.1.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: `Debug` impls for client session values expose TLS secrets
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:240:1
    │
240 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0346
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0346
    ├ The `Debug` implementations of `Tls12ClientSessionValue` and
      `Tls13ClientSessionValue` were derived, and so included the TLS 1.2 master
      secret or TLS 1.3 resumption PSK in their output.
      
      Custom `ClientSessionStore` implementations that format these values with
      `Debug` (for example, when logging) could disclose these secrets to readers of
      the logs. This conflicts with rustls's
      [key-material redaction policy](https://github.com/rustls/rustls/blob/99f2358cae2954837dbb866faf6727de75489ab9/SECURITY.md#boundary-public-api).
      
      Ordinary connection and built-in session cache `Debug` output is redacted and
      is not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3299
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── bin_tests v0.1.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── bin_tests v0.1.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Brotli certificate decompression can allocate up to 1 GiB before authentication
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:240:1
    │
240 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0348
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0348
    ├ The built-in Brotli certificate decompressor (enabled by the non-default
      `brotli` crate feature) bounded the size of the decompressed output, but
      accepted a peer-selected history window. Brotli's large-window extension was
      enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can
      abort a process whose allocator cannot satisfy that request.
      
      No trusted certificate is required by the attacker. Affected configurations are:
      
      - clients that enable the `brotli` feature and connect to a malicious server, and
      - servers that enable the `brotli` feature and request client certificates.
      
      Applications that do not enable the `brotli` feature are not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3297
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── bin_tests v0.1.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── bin_tests v0.1.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Unauthenticated ServerHello can downgrade later connections to classical key exchange
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:240:1
    │
240 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0349
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0349
    ├ The client recorded the server-selected key exchange group for each server
      name when processing the ServerHello, before the server was authenticated.
      This record is used to predict which key share to send in future ClientHellos
      to that server name.
      
      A network attacker can answer one connection attempt with a ServerHello
      selecting X25519, and then close the connection. Later ClientHellos for that
      name carry only an X25519 key share, while `supported_groups` still lists
      X25519MLKEM768 first. If the genuine server accepts that share rather than
      sending a HelloRetryRequest for its preferred hybrid group, the handshake
      completes with classical-only key exchange and no error. This persists for as
      long as the entry stays in the client's session store.
      
      The impact is loss of post-quantum confidentiality for affected connections
      ("harvest now, decrypt later"). There is no key compromise and no
      authentication bypass.
      
      The following are not affected:
      
      - connections to servers which send a HelloRetryRequest for their preferred group,
      - clients with resumption disabled (as nothing is stored), and
      - other server names.
      
      This behaviour is discussed in
      [draft-ietf-tls-key-share-prediction](https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations),
      so the practical impact depends largely on server policy.
    ├ Announcement: https://github.com/rustls/rustls/pull/3355
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── bin_tests v0.1.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── bin_tests v0.1.0 (*)
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[unsound]: `AsyncFd::new` and related constructors violate I/O safety
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:303:1
    │
303 │ tokio 1.49.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0386
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0386
    ├ `tokio::io::unix::AsyncFd` provides safe constructors (`new`, `with_interest`, `try_new`, and `try_with_interest`) that accept any `T: AsRawFd` rather than requiring proof of ownership or validity of the file descriptor. Because `RawFd` implements `AsRawFd`, safe code can construct an `AsyncFd` from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the `AsyncFd` is still alive.
      
      This violates I/O safety in two ways:
      
      1. `AsyncFd<T>` implements `AsFd` for all `T: AsRawFd` by calling `BorrowedFd::borrow_raw(self.as_raw_fd())`, allowing safe code to obtain an arbitrary `BorrowedFd<'_>` without owning the file descriptor.
      2. Tokio's I/O driver stores a pointer to an internal allocation in the `epoll`/`kqueue` user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an `AsyncFd` is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the first `AsyncFd` deregisters the reused file descriptor number and frees the first while the original file description remains registered in `epoll`, leading to a use-after-free when a readiness event fires.
      
      Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, `AsyncFd::new`, `AsyncFd::with_interest`, `AsyncFd::try_new`, and `AsyncFd::try_with_interest` are deprecated in favor of the `unsafe` constructors `AsyncFd::register` and `AsyncFd::register_with_interest`. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the `AsyncFd`.
    ├ Announcement: https://github.com/tokio-rs/tokio/pull/8587
    ├ Solution: Upgrade to >=1.51.6, <1.52.0 OR >=1.53.3 (try `cargo update -p tokio`)
    ├ tokio v1.49.0
      ├── bin_tests v0.1.0
      ├── h2 v0.4.19
      │   └── hyper v1.11.1
      │       ├── httpmock v0.8.0-alpha.1
      │       │   └── (dev) libdd-telemetry v11.0.0
      │       │       └── libdd-crashtracker v3.0.0
      │       │           └── bin_tests v0.1.0 (*)
      │       ├── hyper-rustls v0.27.7
      │       │   └── libdd-common v9.0.0
      │       │       ├── bin_tests v0.1.0 (*)
      │       │       ├── libdd-capabilities-impl v8.0.0
      │       │       │   ├── libdd-crashtracker v3.0.0 (*)
      │       │       │   ├── libdd-shared-runtime v7.0.0
      │       │       │   │   └── libdd-telemetry v11.0.0 (*)
      │       │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       │       ├── libdd-crashtracker v3.0.0 (*)
      │       │       ├── libdd-shared-runtime v7.0.0 (*)
      │       │       └── libdd-telemetry v11.0.0 (*)
      │       ├── hyper-util v0.1.17
      │       │   ├── httpmock v0.8.0-alpha.1 (*)
      │       │   ├── hyper-rustls v0.27.7 (*)
      │       │   └── libdd-common v9.0.0 (*)
      │       └── libdd-common v9.0.0 (*)
      ├── httpmock v0.8.0-alpha.1 (*)
      ├── hyper v1.11.1 (*)
      ├── hyper-rustls v0.27.7 (*)
      ├── hyper-util v0.1.17 (*)
      ├── (dev) libdd-capabilities-impl v8.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── libdd-crashtracker v3.0.0 (*)
      ├── libdd-shared-runtime v7.0.0 (*)
      ├── (dev) libdd-telemetry v11.0.0 (*)
      ├── tokio-rustls v0.26.0
      │   ├── hyper-rustls v0.27.7 (*)
      │   └── (dev) libdd-common v9.0.0 (*)
      ├── tokio-util v0.7.12
      │   ├── h2 v0.4.19 (*)
      │   └── libdd-telemetry v11.0.0 (*)
      └── (dev) tools v48.0.0
          ├── (dev) libdd-common v9.0.0 (*)
          └── (dev) libdd-telemetry v11.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-crashtracker-ffi` - 5 error(s)

Show output

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:255:1
    │
255 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/pull/3265
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── libdd-crashtracker-ffi v48.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: `Debug` impls for client session values expose TLS secrets
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:255:1
    │
255 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0346
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0346
    ├ The `Debug` implementations of `Tls12ClientSessionValue` and
      `Tls13ClientSessionValue` were derived, and so included the TLS 1.2 master
      secret or TLS 1.3 resumption PSK in their output.
      
      Custom `ClientSessionStore` implementations that format these values with
      `Debug` (for example, when logging) could disclose these secrets to readers of
      the logs. This conflicts with rustls's
      [key-material redaction policy](https://github.com/rustls/rustls/blob/99f2358cae2954837dbb866faf6727de75489ab9/SECURITY.md#boundary-public-api).
      
      Ordinary connection and built-in session cache `Debug` output is redacted and
      is not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3299
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── libdd-crashtracker-ffi v48.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Brotli certificate decompression can allocate up to 1 GiB before authentication
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:255:1
    │
255 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0348
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0348
    ├ The built-in Brotli certificate decompressor (enabled by the non-default
      `brotli` crate feature) bounded the size of the decompressed output, but
      accepted a peer-selected history window. Brotli's large-window extension was
      enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can
      abort a process whose allocator cannot satisfy that request.
      
      No trusted certificate is required by the attacker. Affected configurations are:
      
      - clients that enable the `brotli` feature and connect to a malicious server, and
      - servers that enable the `brotli` feature and request client certificates.
      
      Applications that do not enable the `brotli` feature are not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3297
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── libdd-crashtracker-ffi v48.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Unauthenticated ServerHello can downgrade later connections to classical key exchange
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:255:1
    │
255 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0349
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0349
    ├ The client recorded the server-selected key exchange group for each server
      name when processing the ServerHello, before the server was authenticated.
      This record is used to predict which key share to send in future ClientHellos
      to that server name.
      
      A network attacker can answer one connection attempt with a ServerHello
      selecting X25519, and then close the connection. Later ClientHellos for that
      name carry only an X25519 key share, while `supported_groups` still lists
      X25519MLKEM768 first. If the genuine server accepts that share rather than
      sending a HelloRetryRequest for its preferred hybrid group, the handshake
      completes with classical-only key exchange and no error. This persists for as
      long as the entry stays in the client's session store.
      
      The impact is loss of post-quantum confidentiality for affected connections
      ("harvest now, decrypt later"). There is no key compromise and no
      authentication bypass.
      
      The following are not affected:
      
      - connections to servers which send a HelloRetryRequest for their preferred group,
      - clients with resumption disabled (as nothing is stored), and
      - other server names.
      
      This behaviour is discussed in
      [draft-ietf-tls-key-share-prediction](https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations),
      so the practical impact depends largely on server policy.
    ├ Announcement: https://github.com/rustls/rustls/pull/3355
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   └── libdd-crashtracker-ffi v48.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-common-ffi v48.0.0
      │       │   └── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-crashtracker-ffi v48.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[unsound]: `AsyncFd::new` and related constructors violate I/O safety
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:314:1
    │
314 │ tokio 1.49.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0386
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0386
    ├ `tokio::io::unix::AsyncFd` provides safe constructors (`new`, `with_interest`, `try_new`, and `try_with_interest`) that accept any `T: AsRawFd` rather than requiring proof of ownership or validity of the file descriptor. Because `RawFd` implements `AsRawFd`, safe code can construct an `AsyncFd` from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the `AsyncFd` is still alive.
      
      This violates I/O safety in two ways:
      
      1. `AsyncFd<T>` implements `AsFd` for all `T: AsRawFd` by calling `BorrowedFd::borrow_raw(self.as_raw_fd())`, allowing safe code to obtain an arbitrary `BorrowedFd<'_>` without owning the file descriptor.
      2. Tokio's I/O driver stores a pointer to an internal allocation in the `epoll`/`kqueue` user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an `AsyncFd` is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the first `AsyncFd` deregisters the reused file descriptor number and frees the first while the original file description remains registered in `epoll`, leading to a use-after-free when a readiness event fires.
      
      Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, `AsyncFd::new`, `AsyncFd::with_interest`, `AsyncFd::try_new`, and `AsyncFd::try_with_interest` are deprecated in favor of the `unsafe` constructors `AsyncFd::register` and `AsyncFd::register_with_interest`. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the `AsyncFd`.
    ├ Announcement: https://github.com/tokio-rs/tokio/pull/8587
    ├ Solution: Upgrade to >=1.51.6, <1.52.0 OR >=1.53.3 (try `cargo update -p tokio`)
    ├ tokio v1.49.0
      ├── h2 v0.4.19
      │   └── hyper v1.11.1
      │       ├── httpmock v0.8.0-alpha.1
      │       │   └── (dev) libdd-telemetry v11.0.0
      │       │       └── libdd-crashtracker v3.0.0
      │       │           └── libdd-crashtracker-ffi v48.0.0
      │       ├── hyper-rustls v0.27.7
      │       │   └── libdd-common v9.0.0
      │       │       ├── libdd-capabilities-impl v8.0.0
      │       │       │   ├── libdd-crashtracker v3.0.0 (*)
      │       │       │   ├── libdd-shared-runtime v7.0.0
      │       │       │   │   └── libdd-telemetry v11.0.0 (*)
      │       │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       │       ├── libdd-common-ffi v48.0.0
      │       │       │   └── libdd-crashtracker-ffi v48.0.0 (*)
      │       │       ├── libdd-crashtracker v3.0.0 (*)
      │       │       ├── libdd-crashtracker-ffi v48.0.0 (*)
      │       │       ├── libdd-shared-runtime v7.0.0 (*)
      │       │       └── libdd-telemetry v11.0.0 (*)
      │       ├── hyper-util v0.1.17
      │       │   ├── httpmock v0.8.0-alpha.1 (*)
      │       │   ├── hyper-rustls v0.27.7 (*)
      │       │   └── libdd-common v9.0.0 (*)
      │       ├── libdd-common v9.0.0 (*)
      │       └── libdd-common-ffi v48.0.0 (*)
      ├── httpmock v0.8.0-alpha.1 (*)
      ├── hyper v1.11.1 (*)
      ├── hyper-rustls v0.27.7 (*)
      ├── hyper-util v0.1.17 (*)
      ├── (dev) libdd-capabilities-impl v8.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── libdd-crashtracker v3.0.0 (*)
      ├── libdd-shared-runtime v7.0.0 (*)
      ├── (dev) libdd-telemetry v11.0.0 (*)
      ├── tokio-rustls v0.26.0
      │   ├── hyper-rustls v0.27.7 (*)
      │   └── (dev) libdd-common v9.0.0 (*)
      ├── tokio-util v0.7.12
      │   ├── h2 v0.4.19 (*)
      │   └── libdd-telemetry v11.0.0 (*)
      └── (dev) tools v48.0.0
          ├── (dev) libdd-common v9.0.0 (*)
          └── (dev) libdd-telemetry v11.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-crashtracker` - 5 error(s)

Show output

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:234:1
    │
234 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/pull/3265
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: `Debug` impls for client session values expose TLS secrets
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:234:1
    │
234 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0346
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0346
    ├ The `Debug` implementations of `Tls12ClientSessionValue` and
      `Tls13ClientSessionValue` were derived, and so included the TLS 1.2 master
      secret or TLS 1.3 resumption PSK in their output.
      
      Custom `ClientSessionStore` implementations that format these values with
      `Debug` (for example, when logging) could disclose these secrets to readers of
      the logs. This conflicts with rustls's
      [key-material redaction policy](https://github.com/rustls/rustls/blob/99f2358cae2954837dbb866faf6727de75489ab9/SECURITY.md#boundary-public-api).
      
      Ordinary connection and built-in session cache `Debug` output is redacted and
      is not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3299
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Brotli certificate decompression can allocate up to 1 GiB before authentication
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:234:1
    │
234 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0348
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0348
    ├ The built-in Brotli certificate decompressor (enabled by the non-default
      `brotli` crate feature) bounded the size of the decompressed output, but
      accepted a peer-selected history window. Brotli's large-window extension was
      enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can
      abort a process whose allocator cannot satisfy that request.
      
      No trusted certificate is required by the attacker. Affected configurations are:
      
      - clients that enable the `brotli` feature and connect to a malicious server, and
      - servers that enable the `brotli` feature and request client certificates.
      
      Applications that do not enable the `brotli` feature are not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3297
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[vulnerability]: Unauthenticated ServerHello can downgrade later connections to classical key exchange
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:234:1
    │
234 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0349
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0349
    ├ The client recorded the server-selected key exchange group for each server
      name when processing the ServerHello, before the server was authenticated.
      This record is used to predict which key share to send in future ClientHellos
      to that server name.
      
      A network attacker can answer one connection attempt with a ServerHello
      selecting X25519, and then close the connection. Later ClientHellos for that
      name carry only an X25519 key share, while `supported_groups` still lists
      X25519MLKEM768 first. If the genuine server accepts that share rather than
      sending a HelloRetryRequest for its preferred hybrid group, the handshake
      completes with classical-only key exchange and no error. This persists for as
      long as the entry stays in the client's session store.
      
      The impact is loss of post-quantum confidentiality for affected connections
      ("harvest now, decrypt later"). There is no key compromise and no
      authentication bypass.
      
      The following are not affected:
      
      - connections to servers which send a HelloRetryRequest for their preferred group,
      - clients with resumption disabled (as nothing is stored), and
      - other server names.
      
      This behaviour is discussed in
      [draft-ietf-tls-key-share-prediction](https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations),
      so the practical impact depends largely on server policy.
    ├ Announcement: https://github.com/rustls/rustls/pull/3355
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v9.0.0
      │       ├── libdd-capabilities-impl v8.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   ├── libdd-shared-runtime v7.0.0
      │       │   │   └── libdd-telemetry v11.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       ├── libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v7.0.0 (*)
      │       └── libdd-telemetry v11.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v9.0.0 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── (dev) libdd-common v9.0.0 (*)

error[unsound]: `AsyncFd::new` and related constructors violate I/O safety
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:292:1
    │
292 │ tokio 1.49.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0386
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0386
    ├ `tokio::io::unix::AsyncFd` provides safe constructors (`new`, `with_interest`, `try_new`, and `try_with_interest`) that accept any `T: AsRawFd` rather than requiring proof of ownership or validity of the file descriptor. Because `RawFd` implements `AsRawFd`, safe code can construct an `AsyncFd` from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the `AsyncFd` is still alive.
      
      This violates I/O safety in two ways:
      
      1. `AsyncFd<T>` implements `AsFd` for all `T: AsRawFd` by calling `BorrowedFd::borrow_raw(self.as_raw_fd())`, allowing safe code to obtain an arbitrary `BorrowedFd<'_>` without owning the file descriptor.
      2. Tokio's I/O driver stores a pointer to an internal allocation in the `epoll`/`kqueue` user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an `AsyncFd` is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the first `AsyncFd` deregisters the reused file descriptor number and frees the first while the original file description remains registered in `epoll`, leading to a use-after-free when a readiness event fires.
      
      Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, `AsyncFd::new`, `AsyncFd::with_interest`, `AsyncFd::try_new`, and `AsyncFd::try_with_interest` are deprecated in favor of the `unsafe` constructors `AsyncFd::register` and `AsyncFd::register_with_interest`. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the `AsyncFd`.
    ├ Announcement: https://github.com/tokio-rs/tokio/pull/8587
    ├ Solution: Upgrade to >=1.51.6, <1.52.0 OR >=1.53.3 (try `cargo update -p tokio`)
    ├ tokio v1.49.0
      ├── h2 v0.4.19
      │   └── hyper v1.11.1
      │       ├── httpmock v0.8.0-alpha.1
      │       │   └── (dev) libdd-telemetry v11.0.0
      │       │       └── libdd-crashtracker v3.0.0
      │       ├── hyper-rustls v0.27.7
      │       │   └── libdd-common v9.0.0
      │       │       ├── libdd-capabilities-impl v8.0.0
      │       │       │   ├── libdd-crashtracker v3.0.0 (*)
      │       │       │   ├── libdd-shared-runtime v7.0.0
      │       │       │   │   └── libdd-telemetry v11.0.0 (*)
      │       │       │   └── (dev) libdd-telemetry v11.0.0 (*)
      │       │       ├── libdd-crashtracker v3.0.0 (*)
      │       │       ├── libdd-shared-runtime v7.0.0 (*)
      │       │       └── libdd-telemetry v11.0.0 (*)
      │       ├── hyper-util v0.1.17
      │       │   ├── httpmock v0.8.0-alpha.1 (*)
      │       │   ├── hyper-rustls v0.27.7 (*)
      │       │   └── libdd-common v9.0.0 (*)
      │       └── libdd-common v9.0.0 (*)
      ├── httpmock v0.8.0-alpha.1 (*)
      ├── hyper v1.11.1 (*)
      ├── hyper-rustls v0.27.7 (*)
      ├── hyper-util v0.1.17 (*)
      ├── (dev) libdd-capabilities-impl v8.0.0 (*)
      ├── libdd-common v9.0.0 (*)
      ├── libdd-crashtracker v3.0.0 (*)
      ├── libdd-shared-runtime v7.0.0 (*)
      ├── (dev) libdd-telemetry v11.0.0 (*)
      ├── tokio-rustls v0.26.0
      │   ├── hyper-rustls v0.27.7 (*)
      │   └── (dev) libdd-common v9.0.0 (*)
      ├── tokio-util v0.7.12
      │   ├── h2 v0.4.19 (*)
      │   └── libdd-telemetry v11.0.0 (*)
      └── (dev) tools v48.0.0
          ├── (dev) libdd-common v9.0.0 (*)
          └── (dev) libdd-telemetry v11.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-otel-thread-ctx` - ✅ No issues

Updated: 2026-11-09 20:32:37 UTC | Commit: 1a37f0f | dependency-check job results

datadog-prod-us1-4 · 2026-10-29T15:39:37Z

⚠️ Warnings

Your PR has warnings. Please review the issues below.

🚦 1 Pipeline job failed

DDCI - DataDog/libdatadog | build_rust_on_alpine_arm — 🔄 Retry may pass, looks flaky

View more details · View in DDCI

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 28.76%
• Overall Coverage: 70.04% (-13.64%)

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 961c8fb | Docs | View more details | Give us feedback!}

pr-commenter · 2026-10-29T16:03:10Z

Benchmarks

Comparison

Benchmark execution time: 2026-11-09 20:54:52

Comparing candidate commit 961c8fb in PR branch gyuheon0h/PROF-16374-read-otel-thread-ctx with baseline commit 275cd7f in branch main.

📊 Benchmarking dashboard

Found 4 performance improvements and 6 performance regressions! Performance is the same for 139 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:span_pool_v1/wall_time/20x100/allocating

🟩 execution_time [-46.444µs; -46.113µs] or [-7.383%; -7.330%]
🟩 throughput [+251595.650op/s; +253309.697op/s] or [+7.914%; +7.968%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_10/8

🟥 execution_time [+10.126ns; +10.396ns] or [+5.789%; +5.943%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/8

🟥 execution_time [+11.977ns; +12.264ns] or [+6.322%; +6.474%]

scenario:vec_map/dedup/dup_1_in_2/128

🟥 execution_time [+359.824ns; +534.609ns] or [+9.115%; +13.542%]

scenario:vec_map/dedup/dup_1_in_4/128

🟥 execution_time [+286.359ns; +448.599ns] or [+8.398%; +13.157%]

scenario:vec_map/dedup/no_duplicates/128

🟥 execution_time [+147.124ns; +286.943ns] or [+6.475%; +12.629%]

scenario:vec_map/dedup/no_duplicates/64

🟥 execution_time [+52.625ns; +130.107ns] or [+4.245%; +10.495%]

scenario:vec_map/get_hit/64

🟩 execution_time [-3.774µs; -3.749µs] or [-50.918%; -50.586%]
🟩 throughput [+8879315.472op/s; +8916873.342op/s] or [+102.828%; +103.263%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:span_pool/allocated_bytes/1x10/pooled

unstable execution_time [-722.173ns; +395.543ns] or [-51.253%; +28.072%]
unstable throughput [-112063443.877op/s; +114771738.560op/s] or [-234.344%; +240.007%]

scenario:span_pool/allocated_bytes/20x100/pooled

unstable execution_time [-96.887µs; +117.047µs] or [-6.596%; +7.968%]
unstable throughput [-104908.161op/s; +96930.253op/s] or [-7.672%; +7.089%]

scenario:span_pool_v1/allocated_bytes/1x10/pooled

unstable execution_time [-721.917ns; +191.595ns] or [-39.894%; +10.588%]
unstable throughput [-722285.011op/s; +3187768.000op/s] or [-12.075%; +53.290%]

scenario:span_pool_v1/allocated_bytes/20x100/pooled

unstable execution_time [-34.809µs; +147.889µs] or [-2.614%; +11.105%]
unstable throughput [-157633.503op/s; +45444.569op/s] or [-10.459%; +3.015%]

scenario:vec_map/get_mut/8

unstable execution_time [-6.191ns; +4.954ns] or [-6.639%; +5.313%]
unstable throughput [-5435120.099op/s; +5919058.242op/s] or [-6.020%; +6.556%]

Benchmark execution time: 2026-11-09 20:54:52

Comparing candidate commit 961c8fb in PR branch gyuheon0h/PROF-16374-read-otel-thread-ctx with baseline commit 275cd7f in branch main.

📊 Benchmarking dashboard

Found 6 performance improvements and 0 performance regressions! Performance is the same for 89 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:flagevaluation_evp/coalescer/stress/10flags_1000users_250fields

🟩 execution_time [-15.584ms; -14.802ms] or [-7.550%; -7.171%]
🟩 throughput [+374.546op/s; +395.538op/s] or [+7.731%; +8.165%]

scenario:flagevaluation_evp/payloads/scale/2500flags_500users_20fields

🟩 execution_time [-2.046ms; -1.958ms] or [-5.606%; -5.365%]
🟩 throughput [+3888.731op/s; +4060.854op/s] or [+5.678%; +5.929%]

scenario:flagevaluation_evp/payloads/stress/10flags_1000users_250fields

🟩 execution_time [-15.363ms; -15.031ms] or [-7.783%; -7.615%]
🟩 throughput [+417.916op/s; +427.313op/s] or [+8.249%; +8.434%]

Benchmark execution time: 2026-11-09 21:00:53

Comparing candidate commit 961c8fb in PR branch gyuheon0h/PROF-16374-read-otel-thread-ctx with baseline commit 275cd7f in branch main.

📊 Benchmarking dashboard

Found 1 performance improvements and 3 performance regressions! Performance is the same for 70 metrics, 24 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:datadog_sample_span/root_span_no_rules/wall_time

🟥 execution_time [+3.993ns; +4.089ns] or [+4.094%; +4.193%]

scenario:profile_add_sample2_frames_x1000

🟩 execution_time [-36.089µs; -35.887µs] or [-4.992%; -4.964%]

scenario:trace_buffer/8_senders/no_delay

🟥 execution_time [+331.395µs; +369.149µs] or [+6.085%; +6.778%]
🟥 throughput [-84167.728op/s; -75597.136op/s] or [-6.366%; -5.718%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:datadog_sample_span/complex_rule_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/complex_rule_partial_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/many_attributes_tag_rule/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+551.925%; -553.945%]

scenario:datadog_sample_span/multiple_rules_first_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+557.386%; -556.513%]

scenario:datadog_sample_span/multiple_rules_last_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/name_pattern_rule_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+544.893%; -550.663%]

scenario:datadog_sample_span/name_pattern_rule_not_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+550.110%; -553.096%]

scenario:datadog_sample_span/parent_not_sampled_short_circuit/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+557.771%; -556.694%]

scenario:datadog_sample_span/parent_sampled_short_circuit/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/resource_pattern_rule_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/resource_pattern_rule_not_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+564.559%; -559.908%]

scenario:datadog_sample_span/root_span_no_rules/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+557.779%; -556.698%]

scenario:datadog_sample_span/service_rule_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+559.144%; -557.343%]

scenario:datadog_sample_span/service_rule_not_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+553.474%; -554.672%]

scenario:datadog_sample_span/tag_rule_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:datadog_sample_span/tag_rule_not_matching/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+558.144%; -556.870%]

scenario:glob_matcher/ascii_case_insensitive_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+556.322%; -556.011%]

scenario:glob_matcher/ascii_exact_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.735%; -555.735%]

scenario:glob_matcher/ascii_exact_miss/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.978%; -555.849%]

scenario:glob_matcher/ascii_wildcard_backtrack_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+554.079%; -554.956%]

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+558.350%; -556.967%]

scenario:glob_matcher/ascii_wildcard_question_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+554.086%; -554.959%]

scenario:glob_matcher/ascii_wildcard_star_match/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+557.386%; -556.513%]

scenario:glob_matcher/star_short_circuit/allocated_bytes

unstable execution_time [-0.000ns; +0.000ns] or [+555.543%; -555.644%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

dd-octo-sts · 2026-10-29T19:32:33Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	96.31 MB	96.45 MB	+.14% (+144.26 KB) 🔍
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	9.21 MB	9.21 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	107.46 MB	107.60 MB	+.13% (+144.77 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	12.38 MB	12.39 MB	+.03% (+3.86 KB) 🔍

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	29.64 MB	29.67 MB	+.10% (+31.50 KB) 🔍
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	99.96 KB	99.96 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	192.39 MB	192.60 MB	+.10% (+216.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	800.37 MB	801.67 MB	+.16% (+1.30 MB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	9.74 MB	9.75 MB	+.11% (+11.50 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	99.96 KB	99.96 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	27.77 MB	27.80 MB	+.08% (+24.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	55.87 MB	55.90 MB	+.05% (+34.01 KB) 🔍

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	26.13 MB	26.16 MB	+.10% (+29.00 KB) 🔍
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	101.51 KB	101.51 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	198.13 MB	198.30 MB	+.08% (+176.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	785.38 MB	786.33 MB	+.12% (+973.06 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	7.51 MB	7.52 MB	+.07% (+5.50 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	101.51 KB	101.51 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	29.87 MB	29.88 MB	+.05% (+16.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	52.75 MB	52.78 MB	+.05% (+29.73 KB) 🔍

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	86.80 MB	86.93 MB	+.15% (+134.31 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	10.03 MB	10.04 MB	+.15% (+16.00 KB) 🔍

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	102.52 MB	102.65 MB	+.13% (+139.47 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	12.28 MB	12.29 MB	+.13% (+16.65 KB) 🔍

chatgpt-codex-connector · 2026-11-05T17:47:42Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-05T18:14:15.056808Z	`d5bc3b1`	Manual request

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 07ba83e800

ℹ️ 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".

gyuheon0h · 2026-11-05T18:10:48Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d5bc3b182d

ℹ️ 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".

yannham

Still some comments, but non blocking.

yannham

(missed otel_tls_reader.rs changes)

github-actions Bot added the crashtracker label Oct 29, 2026

gyuheon0h changed the title ~~Initial code pass at reading crashing thread context~~ feat(crashtracking): read crashing thread context Oct 29, 2026

gyuheon0h changed the title ~~feat(crashtracking): read crashing thread context~~ feat(crashtracking)!: read crashing thread context Oct 29, 2026

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch from d7e040e to bebb69c Compare October 29, 2026 15:50

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch 2 times, most recently from 3e0583d to ee5fd65 Compare October 29, 2026 17:58

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch 8 times, most recently from a11738c to 07ba83e Compare November 5, 2026 17:46

gyuheon0h marked this pull request as ready for review November 5, 2026 17:47

gyuheon0h requested review from a team as code owners November 5, 2026 17:47

chatgpt-codex-connector Bot reviewed Nov 5, 2026

View reviewed changes

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch from 07ba83e to d5bc3b1 Compare November 5, 2026 18:05

chatgpt-codex-connector Bot reviewed Nov 5, 2026

View reviewed changes

Comment thread libdd-crashtracker/src/collector/emitters.rs Resolved

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch 2 times, most recently from b024855 to 0be8af3 Compare November 5, 2026 19:01

gyuheon0h requested a review from yannham November 5, 2026 19:02

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch from 0be8af3 to f1c90d7 Compare November 5, 2026 19:46

gyuheon0h commented Nov 5, 2026

View reviewed changes

Comment thread libdd-crashtracker/src/collector/emitters.rs Resolved

yannham reviewed Nov 6, 2026

View reviewed changes

gyuheon0h added 4 commits November 9, 2026 14:14

feat: read crashing thread context

a8a45df

feat: collect all thread's contexts

3b9e8f2

refactor: read in collector and pipe over to receiver

ee24fcc

fix: use DTV to find offset

cae628d

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch 4 times, most recently from 0aaeb57 to e8e8bdd Compare November 9, 2026 16:30

gyuheon0h requested a review from yannham November 9, 2026 16:30

fix: no need to read full 640

77ab4ff

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch 2 times, most recently from 1f62ead to e516e83 Compare November 9, 2026 17:23

yannham approved these changes Nov 9, 2026

View reviewed changes

Comment thread libdd-otel-thread-ctx/src/linux.rs Resolved

Comment thread libdd-otel-thread-ctx/src/linux.rs Resolved

Comment thread libdd-otel-thread-ctx/src/linux.rs Resolved

yannham reviewed Nov 9, 2026

View reviewed changes

Comment thread libdd-crashtracker/src/otel_tls_reader.rs Resolved

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch 5 times, most recently from 0a2e68d to a613018 Compare November 9, 2026 20:11

fix: fall back to single TP-relative offset

cf10e4a

gyuheon0h force-pushed the gyuheon0h/PROF-16374-read-otel-thread-ctx branch from a613018 to cf10e4a Compare November 9, 2026 20:13

refactor: clean up

961c8fb

Conversation

gyuheon0h commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Additional Notes

How to test the change?

Uh oh!

gyuheon0h commented Oct 29, 2026

Uh oh!

github-actions Bot commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 bin_tests - 1097 warning(s)

📦 libdd-crashtracker-ffi - 1152 warning(s)

📦 libdd-crashtracker - 980 warning(s)

📦 libdd-otel-thread-ctx - 1 warning(s)

Uh oh!

github-actions Bot commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 bin_tests - 5 error(s)

📦 libdd-crashtracker-ffi - 5 error(s)

📦 libdd-crashtracker - 5 error(s)

📦 libdd-otel-thread-ctx - ✅ No issues

Uh oh!

datadog-prod-us1-4 Bot commented Oct 29, 2026 • edited by datadog-prod-us1-6 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Warnings

ℹ️ Info

Uh oh!

pr-commenter Bot commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:span_pool_v1/wall_time/20x100/allocating

scenario:vec_map/as_deduped_map/needs_dedup_1_in_10/8

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/8

scenario:vec_map/dedup/dup_1_in_2/128

scenario:vec_map/dedup/dup_1_in_4/128

scenario:vec_map/dedup/no_duplicates/128

scenario:vec_map/dedup/no_duplicates/64

scenario:vec_map/get_hit/64

Unstable benchmarks

scenario:span_pool/allocated_bytes/1x10/pooled

scenario:span_pool/allocated_bytes/20x100/pooled

scenario:span_pool_v1/allocated_bytes/1x10/pooled

scenario:span_pool_v1/allocated_bytes/20x100/pooled

scenario:vec_map/get_mut/8

Explanation

More details about the CI and significant changes

scenario:flagevaluation_evp/coalescer/stress/10flags_1000users_250fields

scenario:flagevaluation_evp/payloads/scale/2500flags_500users_20fields

scenario:flagevaluation_evp/payloads/stress/10flags_1000users_250fields

Explanation

More details about the CI and significant changes

scenario:datadog_sample_span/root_span_no_rules/wall_time

scenario:profile_add_sample2_frames_x1000

scenario:trace_buffer/8_senders/no_delay

Unstable benchmarks

scenario:datadog_sample_span/complex_rule_matching/allocated_bytes

scenario:datadog_sample_span/complex_rule_partial_match/allocated_bytes

scenario:datadog_sample_span/many_attributes_tag_rule/allocated_bytes

scenario:datadog_sample_span/multiple_rules_first_match/allocated_bytes

scenario:datadog_sample_span/multiple_rules_last_match/allocated_bytes

scenario:datadog_sample_span/name_pattern_rule_matching/allocated_bytes

scenario:datadog_sample_span/name_pattern_rule_not_matching/allocated_bytes

scenario:datadog_sample_span/parent_not_sampled_short_circuit/allocated_bytes

scenario:datadog_sample_span/parent_sampled_short_circuit/allocated_bytes

scenario:datadog_sample_span/resource_pattern_rule_matching/allocated_bytes

scenario:datadog_sample_span/resource_pattern_rule_not_matching/allocated_bytes

scenario:datadog_sample_span/root_span_no_rules/allocated_bytes

scenario:datadog_sample_span/service_rule_matching/allocated_bytes

scenario:datadog_sample_span/service_rule_not_matching/allocated_bytes

scenario:datadog_sample_span/tag_rule_matching/allocated_bytes

scenario:datadog_sample_span/tag_rule_not_matching/allocated_bytes

scenario:glob_matcher/ascii_case_insensitive_match/allocated_bytes

scenario:glob_matcher/ascii_exact_match/allocated_bytes

gyuheon0h commented Oct 29, 2026 •

edited

Loading

github-actions Bot commented Oct 29, 2026 •

edited

Loading

📦 `bin_tests` - 1097 warning(s)

📦 `libdd-crashtracker-ffi` - 1152 warning(s)

📦 `libdd-crashtracker` - 980 warning(s)

📦 `libdd-otel-thread-ctx` - 1 warning(s)

github-actions Bot commented Oct 29, 2026 •

edited

Loading

📦 `bin_tests` - 5 error(s)

📦 `libdd-crashtracker-ffi` - 5 error(s)

📦 `libdd-crashtracker` - 5 error(s)

📦 `libdd-otel-thread-ctx` - ✅ No issues

datadog-prod-us1-4 Bot commented Oct 29, 2026 •

edited by datadog-prod-us1-6 Bot

Loading

pr-commenter Bot commented Oct 29, 2026 •

edited

Loading

dd-octo-sts Bot commented Oct 29, 2026 •

edited

Loading

chatgpt-codex-connector Bot commented Nov 5, 2026 •

edited

Loading