feat(crashtracking): retrieve c assert message for linux when `__assert_fail` is dynamically loaded by gyuheon0h · Pull Request #2268 · DataDog/libdatadog

gyuheon0h · 2026-07-23T16:33:14Z

Stacked above: feat(got-hook): add DT_HASH fallback, relocation type guard, and hook_symbol

What does this PR do?

When a process crashes due to a C assert() failure, the crash report now includes the assertion expression string (Assertion failed: (x > 0), function foo, file bar.c, line 42) in error.message, instead of just reporting a bare SIGABRT.

When a shared library calls an external function like __assert_fail, it doesn't jump directly to the target. Instead, it jumps through the global offset table. Every shared library has its own GOT with its own slot for each external function it calls.
We overwrites the slots at runtime for __assert_fail so calls are redirected to our hook function. My initial thought was to use LD_PRELOAD but this approach works no matter the load order.

I was inspired by libdd-profiling-heap-gotter which does something similar to intercept malloc/free for heap profiling.

During crashtracker::init(), install_assert_hook()

Resolves the original assertion handler
Enumerate loaded ELF objects
Inspect dynamic relocation tables
parses each object’s PT_DYNAMIC segment to locate its relocation tables
Patch references to __assert_fail

When a C assert() fails:
The hook captures the assertion expression, file name, line no, func name, and stores it through an atomic pointer:

The hook calls the original __assert_fail() implementation.
The original implementation calls abort(), which raises SIGABRT.
The crashtracker signal handler checks the stored assertion metadata
The assertion details are included in the resulting crash report.

Unfortunately, this doesn't work everywhere

Linux 64-bit (glibc): Full support with GOT patching.
Linux 64-bit (musl/Alpine): Best-effort since if libc is statically linked, __assert_fail has no GOT entry to patch. The hook installs silently as a no-op.
Other platforms: No-op. install_assert_hook() compiles to an empty function.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

How to test the change?

{
  "counters": {
    "profiler_collecting_sample": 1,
    "profiler_inactive": 0,
    "profiler_serializing": 0,
    "profiler_unwinding": 0
  },
  "data_schema_version": "1.8",
  "error": {
    "is_crash": true,
    "kind": "UnixSignal",
    "message": "Assertion failed: (test_value > 0), function trigger_c_assert, file src/c/trigger_assert.c, line 12.",
    "source_type": "Crashtracking",
    "stack": {
      "format": "Datadog Crashtracker 1.0",
      "frames": [
        {
          "build_id": "4f7b0c955c3d81d7cac1501a2498b69d1d82bfe7",
          "build_id_type": "GNU",
          "column": 10,
          "file": "./nptl/pthread_kill.c",
          "file_type": "ELF",
          "function": "__GI___pthread_kill",
          "ip": "0x727c09d7b9fc",
          "line": 89,
          "module_base_address": "0x727c09ce5000",
          "path": "/usr/lib/x86_64-linux-gnu/libc.so.6",
          "relative_address": "0x00000000000969fc",
          "sp": "0x7ffc91dce470",
          "symbol_address": "0x727c09d7b8d0"
        },
        {
          "build_id": "4f7b0c955c3d81d7cac1501a2498b69d1d82bfe7",
          "build_id_type": "GNU",
          "column": 6,
          "file": "./signal/../sysdeps/posix/raise.c",
          "file_type": "ELF",
          "function": "__GI_raise",
          "ip": "0x727c09d27476",
          "line": 27,
          "module_base_address": "0x727c09ce5000",
          "path": "/usr/lib/x86_64-linux-gnu/libc.so.6",
          "relative_address": "0x0000000000042476",
          "sp": "0x7ffc91dce530",
          "symbol_address": "0x727c09d27460"
        },
        {
          "build_id": "4f7b0c955c3d81d7cac1501a2498b69d1d82bfe7",
          "build_id_type": "GNU",
          "column": 7,
          "file": "./stdlib/abort.c",
          "file_type": "ELF",
          "function": "__GI_abort",
          "ip": "0x727c09d0d7f3",
          "line": 81,
          "module_base_address": "0x727c09ce5000",
          "path": "/usr/lib/x86_64-linux-gnu/libc.so.6",
          "relative_address": "0x00000000000287f3",
          "sp": "0x7ffc91dce540",
          "symbol_address": "0x727c09d0d720"
        },
        {
          "build_id": "4f7b0c955c3d81d7cac1501a2498b69d1d82bfe7",
          "build_id_type": "GNU",
          "column": 9,
          "file": "./intl/loadmsgcat.c",
          "file_type": "ELF",
          "function": "_nl_load_domain",
          "ip": "0x727c09d0d71b",
          "line": 1177,
          "module_base_address": "0x727c09ce5000",
          "path": "/usr/lib/x86_64-linux-gnu/libc.so.6",
          "relative_address": "0x000000000002871b",
          "sp": "0x7ffc91dce680"
        },
        {
          "build_id": "4f7b0c955c3d81d7cac1501a2498b69d1d82bfe7",
          "build_id_type": "GNU",
          "comments": [
            "resolve_names failed with Couldn't symbolize 125877066264214: address not found in symbolization source"
          ],
          "file_type": "ELF",
          "ip": "0x727c09d1ee96",
          "module_base_address": "0x727c09ce5000",
          "path": "/usr/lib/x86_64-linux-gnu/libc.so.6",
          "relative_address": "0x0000000000039e96",
          "sp": "0x7ffc91dce6d0"
        },
        {
          "build_id": "a7ba23793697db2e70bfbe6648326398eed71003",
          "build_id_type": "GNU",
          "column": 5,
          "file": "/home/bits/go/src/github.com/DataDog/libdatadog/libdd-crashtracker/src/collector/assert_interceptor.rs",
          "file_type": "ELF",
          "function": "hook_assert_fail",
          "ip": "0x63a727372d46",
          "line": 92,
          "module_base_address": "0x63a727324000",
          "path": "/home/bits/go/src/github.com/DataDog/libdatadog/target/release/crashtracker_bin_test",
          "relative_address": "0x000000000004ed46",
          "sp": "0x7ffc91dce700"
        },
        {
          "build_id": "a7ba23793697db2e70bfbe6648326398eed71003",
          "build_id_type": "GNU",
          "file_type": "ELF",
          "function": "trigger_c_assert",
          "ip": "0x63a7273b319b",
          "module_base_address": "0x63a727324000",
          "path": "/home/bits/go/src/github.com/DataDog/libdatadog/target/release/crashtracker_bin_test",
          "relative_address": "0x000000000008f19b",
          "sp": "0x7ffc91dce7e0"
        },
        {
          "build_id": "a7ba23793697db2e70bfbe6648326398eed71003",
          "build_id_type": "GNU",
          "column": 5,
          "file": "/home/bits/go/src/github.com/DataDog/libdatadog/bin_tests/src/bin/crashtracker_bin_test.rs",
          "file_type": "ELF",
          "function": "main",
          "ip": "0x63a727351f78",
          "line": 9,
          "module_base_address": "0x63a727324000",
          "path": "/home/bits/go/src/github.com/DataDog/libdatadog/target/release/crashtracker_bin_test",
          "relative_address": "0x000000000002df78",
          "sp": "0x7ffc91dce800"
        },
        {
          "build_id": "a7ba23793697db2e70bfbe6648326398eed71003",
          "build_id_type": "GNU",
          "column": 2,
          "file": "/home/bits/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs",
          "file_type": "ELF",
          "function": "__rust_begin_short_backtrace<fn() -> core::result::Result<(), anyhow::Error>, core::result::Result<(), anyhow::Error>>",
          "ip": "0x63a72735283b",
          "line": 172,
          "module_base_address": "0x63a727324000",
          "path": "/home/bits/go/src/github.com/DataDog/libdatadog/target/release/crashtracker_bin_test",
          "relative_address": "0x000000000002e83b",
          "sp": "0x7ffc91dcf000"
        },
        {
          "build_id": "a7ba23793697db2e70bfbe6648326398eed71003",
          "build_id_type": "GNU",
          "file_type": "ELF",
          "function": "main",
          "ip": "0x63a727353cd9",
          "module_base_address": "0x63a727324000",
          "path": "/home/bits/go/src/github.com/DataDog/libdatadog/target/release/crashtracker_bin_test",
          "relative_address": "0x000000000002fcd9",
          "sp": "0x7ffc91dcf010"
        },
        {
          "build_id": "4f7b0c955c3d81d7cac1501a2498b69d1d82bfe7",
          "build_id_type": "GNU",
          "column": 16,
          "file": "./csu/../sysdeps/nptl/libc_start_call_main.h",
          "file_type": "ELF",
          "function": "__libc_start_call_main",
          "ip": "0x727c09d0ed90",
          "line": 58,
          "module_base_address": "0x727c09ce5000",
          "path": "/usr/lib/x86_64-linux-gnu/libc.so.6",
          "relative_address": "0x0000000000029d90",
          "sp": "0x7ffc91dcf110"
        },
        {
          "build_id": "4f7b0c955c3d81d7cac1501a2498b69d1d82bfe7",
          "build_id_type": "GNU",
          "column": 5,
          "file": "./csu/../csu/libc-start.c",
          "file_type": "ELF",
          "function": "__libc_start_main_impl",
          "ip": "0x727c09d0ee40",
          "line": 379,
          "module_base_address": "0x727c09ce5000",
          "path": "/usr/lib/x86_64-linux-gnu/libc.so.6",
          "relative_address": "0x0000000000029e40",
          "sp": "0x7ffc91dcf1b0",
          "symbol_address": "0x727c09d0edc0"
        },
        {
          "build_id": "a7ba23793697db2e70bfbe6648326398eed71003",
          "build_id_type": "GNU",
          "file_type": "ELF",
          "function": "_start",
          "ip": "0x63a727350b25",
          "module_base_address": "0x63a727324000",
          "path": "/home/bits/go/src/github.com/DataDog/libdatadog/target/release/crashtracker_bin_test",
          "relative_address": "0x000000000002cb25",
          "sp": "0x7ffc91dcf200"
        }
      ],
      "incomplete": false
    },
    "thread_name": "crashtracker_bi"
  },
  "experimental": {},
  "files": {
    "/proc/self/maps": [
      "63a727324000-63a727350000 r--p 00000000 103:03 19137659                  /home/bits/go/src/github.com/DataDog/libdatadog/target/release/crashtracker_bin_test",
...
      "7ffc91dd6000-7ffc91dda000 r--p 00000000 00:00 0                          [vvar]",
      "7ffc91dda000-7ffc91ddc000 r-xp 00000000 00:00 0                          [vdso]",
      "ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]",
      ""
    ]
  },
  "incomplete": false,
  "log_messages": [
    "Error resolving frames: normalize_ips: Ok(())\tresolve_names: Err(Failed to resolve names, see frame comments for details)"
  ],
  "metadata": {
    "family": "native",
    "library_name": "libdatadog",
    "library_version": "1.0.0",
    "tags": [
      "service:foo",
      "service_version:bar",
      "runtime-id:xyz",
      "language:native"
    ]
  },
  "os_info": {
    "architecture": "x86_64",
    "bitness": "64-bit",
    "os_type": "Ubuntu",
    "version": "22.4.0"
  },
  "proc_info": {
    "pid": 3004337,
    "tid": 3004337
  },
  "sig_info": {
    "si_code": -6,
    "si_code_human_readable": "SI_TKILL",
    "si_signo": 6,
    "si_signo_human_readable": "SIGABRT"
  },
  "timestamp": "2026-07-27 15:40:47.932376685 UTC",
  "ucontext": {
    "arch": "x86_64",
    "raw": ...,
    "registers": {
      "r10": "0x0000000000000008",
...
      "rsp": "0x00007ffc91dce470"
    }
  },
  "uuid": "be0eefee-dd24-4588-b377-a5c144dc1177"
}

gyuheon0h · 2026-07-23T16:33:30Z

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

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

pr-commenter · 2026-07-23T16:44:07Z

Benchmarks

Comparison

Benchmark execution time: 2026-07-30 21:47:57

Comparing candidate commit 34cd4ce in PR branch gyuheon0h/PROF-15482-c-assert-msg with baseline commit d224c5d in branch gyuheon0h/got-hook-utils.

Found 5 performance improvements and 5 performance regressions! Performance is the same for 167 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_system_fast_path/4096

🟩 execution_time [-12.504ns; -12.448ns] or [-13.763%; -13.702%]

scenario:datadog_sample_span/multiple_rules_last_match/wall_time

🟥 execution_time [+14.472ns; +14.602ns] or [+7.331%; +7.397%]

scenario:ddsketch_encode/into_pb/clustered_near_zero

🟥 execution_time [+6.337ns; +6.947ns] or [+18.399%; +20.171%]

scenario:ddsketch_encode/into_pb/collapsing

🟥 execution_time [+5.741ns; +6.730ns] or [+15.085%; +17.684%]

scenario:ddsketch_encode/into_pb/large_values

🟥 execution_time [+5.768ns; +6.410ns] or [+16.396%; +18.224%]

scenario:ddsketch_encode/into_pb/mixed

🟥 execution_time [+6.075ns; +6.912ns] or [+16.953%; +19.289%]

scenario:glob_matcher/unicode_pattern_ascii_subject/wall_time

🟩 execution_time [-4.673ns; -4.597ns] or [-4.940%; -4.859%]

scenario:glob_matcher/unicode_pattern_wildcard_match/wall_time

🟩 execution_time [-8.278ns; -8.200ns] or [-6.215%; -6.157%]

scenario:trace_buffer/4_senders/no_delay

🟩 execution_time [-264.729µs; -237.667µs] or [-10.603%; -9.519%]
🟩 throughput [+153502.605op/s; +172278.653op/s] or [+10.642%; +11.943%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

datadog-datadog-prod-us1-2 · 2026-07-23T17:01:31Z

⚠️ Warnings

❄️ 1 New flaky test detected

collector::assert_interceptor::tests::test_install_assert_hook from libdd-crashtracker

View in Flaky Test Management

ℹ️ Info

No other issues found (see more)

🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 62.11%
• Overall Coverage: 74.84% (-0.05%)

Useful? React with 👍 / 👎

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

🔗 Commit SHA: 34cd4ce | Docs | Datadog PR Page | Give us feedback!}

dd-octo-sts · 2026-07-23T19:07:44Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	87.33 MB	87.46 MB	+.15% (+138.64 KB) 🔍
/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.59 MB	98.71 MB	+.11% (+115.85 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.78 MB	10.78 MB	+.02% (+2.98 KB) 🔍

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	26.08 MB	26.08 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	89.60 KB	89.60 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	188.23 MB	188.23 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	980.23 MB	980.23 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.48 MB	8.48 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	89.60 KB	89.60 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	25.08 MB	25.08 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	49.90 MB	49.90 MB	0% (0 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.65 MB	22.65 MB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	91.00 KB	91.00 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	192.71 MB	192.72 MB	+0% (+8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	971.14 MB	971.14 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.55 MB	6.55 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	91.00 KB	91.00 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	26.94 MB	26.94 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	47.50 MB	47.50 MB	0% (0 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	77.82 MB	77.96 MB	+.18% (+150.33 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.93 MB	8.94 MB	+.13% (+12.00 KB) 🔍

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	93.38 MB	93.53 MB	+.15% (+151.59 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.87 MB	10.88 MB	+.12% (+14.18 KB) 🔍

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7568fed720

ℹ️ 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 · 2026-07-27T15:51:01Z

Have yet to look at it, but as a preamble, do you think there's some way to reuse or share the code from libdd-profiling-heap-gotter? It seems some type definitions at least, and probably some functions as well are very similar, if not the same.

gyuheon0h · 2026-07-27T15:52:13Z

Have yet to look at it, but as a preamble, do you think there's some way to reuse or share the code from libdd-profiling-heap-gotter? It seems some type definitions at least, and probably some functions as well are very similar, if not the same.

@yannham Yeah. Maybe I shouldn't have opened this yet.

github-actions · 2026-07-29T17:00:11Z

📚 Documentation Check Results

⚠️ 2988 documentation warning(s) found

📦 `bin_tests` - 1704 warning(s)

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

📦 `tools` - 173 warning(s)

Updated: 2026-07-30 21:04:26 UTC | Commit: 851c1b1 | missing-docs job results

github-actions · 2026-07-29T17:00:59Z

🔒 Cargo Deny Results

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

📦 `bin_tests` - 4 error(s)

Show output

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:73:1
   │
73 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               ├── (dev) libdd-crashtracker v1.0.0
     │               │   └── bin_tests v0.1.0
     │               ├── (dev) libdd-ddsketch v1.1.0
     │               │   └── libdd-telemetry v6.0.0
     │               │       └── libdd-crashtracker v1.0.0 (*)
     │               └── (dev) libdd-profiling v1.0.0
     │                   ├── bin_tests v0.1.0 (*)
     │                   └── (dev) libdd-profiling v1.0.0 (*)
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 ├── libdd-common v5.1.0
                 │   ├── bin_tests v0.1.0 (*)
                 │   ├── libdd-capabilities-impl v3.0.0
                 │   │   ├── libdd-crashtracker v1.0.0 (*)
                 │   │   ├── libdd-shared-runtime v2.0.0
                 │   │   │   └── libdd-telemetry v6.0.0 (*)
                 │   │   └── (dev) libdd-telemetry v6.0.0 (*)
                 │   ├── (build) libdd-crashtracker v1.0.0 (*)
                 │   ├── libdd-profiling v1.0.0 (*)
                 │   ├── libdd-shared-runtime v2.0.0 (*)
                 │   └── libdd-telemetry v6.0.0 (*)
                 └── libdd-profiling v1.0.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:124:1
    │
124 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0118
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
    ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
      `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
      list of candidate encloser names. The iterator used assumes the
      QNAME is a descendant of the SOA owner, terminating only when the current
      candidate equals the SOA name. When the SOA in a response's authority section
      is not an ancestor of the QNAME, the loop stalls at the DNS root and never
      terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
      `Name` and hashed-name entries into the candidate `Vec`.
      
      The bug is reachable by any caller of `DnssecDnsHandle` — including the
      resolver, recursor, and client — when built with the `dnssec-ring` or
      `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
      triggered while validating a NoData or NXDomain response whose authority
      section contains an SOA record from a zone other than an ancestor of the
      QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
      this can be reached through an insecure CNAME chain that crosses zone
      boundaries into a DNSSEC-signed zone returning NoData, but the minimum
      condition is just a mismatched SOA owner on a response requiring NSEC3
      validation.
      
      A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
      abort with a panic on the first iteration past the root. Release builds
      compile the assertion out and run the loop unbounded, allocating until the
      process exhausts available memory (OOM). A reachable upstream attacker who
      can return such a response can therefore crash a debug-built validator or
      exhaust memory on a release-built one.
      
      The affected code was migrated from `hickory-proto` to `hickory-net` as part of
      the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
      `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
      0.26.1 when the implementation of that type is required.
    ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
    ├ Solution: No safe upgrade is available!
    ├ hickory-proto v0.25.2
      └── hickory-resolver v0.25.2
          └── reqwest v0.13.2
              ├── libdd-common v5.1.0
              │   ├── bin_tests v0.1.0
              │   ├── libdd-capabilities-impl v3.0.0
              │   │   ├── libdd-crashtracker v1.0.0
              │   │   │   └── bin_tests v0.1.0 (*)
              │   │   ├── libdd-shared-runtime v2.0.0
              │   │   │   └── libdd-telemetry v6.0.0
              │   │   │       └── libdd-crashtracker v1.0.0 (*)
              │   │   └── (dev) libdd-telemetry v6.0.0 (*)
              │   ├── (build) libdd-crashtracker v1.0.0 (*)
              │   ├── libdd-profiling v1.0.0
              │   │   ├── bin_tests v0.1.0 (*)
              │   │   └── (dev) libdd-profiling v1.0.0 (*)
              │   ├── libdd-shared-runtime v2.0.0 (*)
              │   └── libdd-telemetry v6.0.0 (*)
              └── libdd-profiling v1.0.0 (*)

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:124:1
    │
124 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0119
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
    ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
      labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
      The name compression logic then searches for matches with a linear scan.
      
      A malicious message with many records can both introduce many candidate labels,
      and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
      attacks.
      
      This is similar to
      [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
      
      We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
    ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
    ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
    ├ hickory-proto v0.25.2
      └── hickory-resolver v0.25.2
          └── reqwest v0.13.2
              ├── libdd-common v5.1.0
              │   ├── bin_tests v0.1.0
              │   ├── libdd-capabilities-impl v3.0.0
              │   │   ├── libdd-crashtracker v1.0.0
              │   │   │   └── bin_tests v0.1.0 (*)
              │   │   ├── libdd-shared-runtime v2.0.0
              │   │   │   └── libdd-telemetry v6.0.0
              │   │   │       └── libdd-crashtracker v1.0.0 (*)
              │   │   └── (dev) libdd-telemetry v6.0.0 (*)
              │   ├── (build) libdd-crashtracker v1.0.0 (*)
              │   ├── libdd-profiling v1.0.0
              │   │   ├── bin_tests v0.1.0 (*)
              │   │   └── (dev) libdd-profiling v1.0.0 (*)
              │   ├── libdd-shared-runtime v2.0.0 (*)
              │   └── libdd-telemetry v6.0.0 (*)
              └── libdd-profiling v1.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:242:1
    │
242 │ 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
      │   ├── bin_tests v0.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-crashtracker v1.0.0
      │   │   │   └── bin_tests v0.1.0 (*)
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   └── libdd-telemetry v6.0.0
      │   │   │       └── libdd-crashtracker v1.0.0 (*)
      │   │   └── (dev) libdd-telemetry v6.0.0 (*)
      │   ├── (build) libdd-crashtracker v1.0.0 (*)
      │   ├── libdd-profiling v1.0.0
      │   │   ├── bin_tests v0.1.0 (*)
      │   │   └── (dev) libdd-profiling v1.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   └── libdd-telemetry v6.0.0 (*)
      ├── libdd-crashtracker v1.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   └── libdd-telemetry v6.0.0 (*)
      ├── libdd-profiling v1.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-profiling v1.0.0 (*)

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:59:1
   │
59 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── (dev) libdd-crashtracker v1.0.0
                     └── (dev) libdd-ddsketch v1.1.0
                         └── libdd-telemetry v6.0.0
                             └── libdd-crashtracker v1.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:205:1
    │
205 │ 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
      ├── libdd-common v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-crashtracker v1.0.0
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   └── libdd-telemetry v6.0.0
      │   │   │       └── libdd-crashtracker v1.0.0 (*)
      │   │   └── (dev) libdd-telemetry v6.0.0 (*)
      │   ├── (build) libdd-crashtracker v1.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   └── libdd-telemetry v6.0.0 (*)
      ├── libdd-crashtracker v1.0.0 (*)
      └── (dev) libdd-ddsketch v1.1.0
          └── libdd-telemetry v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `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:71:1
   │
71 │ 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 v38.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:71:1
   │
71 │ 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 v38.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:74:1
   │
74 │ 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 v38.0.0

advisories FAILED, bans ok, sources ok

Updated: 2026-07-30 21:05:13 UTC | Commit: 851c1b1 | dependency-check job results

Hook __assert_fail via GOT patching (using libdd-got-hook) during crashtracker init. When a C assert() fails, the hook captures the assertion expression, file, line, and function name before the process aborts via SIGABRT. The signal handler includes this message in the crash report. Only supported on 64-bit Linux; no-op on other platforms.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 34cd4cebfb

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

chatgpt-codex-connector · 2026-07-30T21:12:55Z

+    let message_ptr = if message_ptr.is_null() {
+        super::assert_interceptor::take_assert_message_ptr()
+    } else {
+        message_ptr


Prefer captured assert messages over stale panic messages

If the process has a Rust panic that is caught after crashtracker initialization, the panic hook leaves PANIC_MESSAGE non-null until the next signal; when a later C assert() aborts, hook_assert_fail has already stored the assertion details, but this branch keeps the stale panic text and never reads the assert message, so the crash report describes the old panic instead of the actual assertion failure. Prefer the assert message for SIGABRT/assert-hook crashes or clear stale panic state before ignoring the new message.

AGENTS.md reference: AGENTS.md:L70-L73

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-07-30T21:12:55Z

+    let message = format_assert_message(assertion_str, file_str, line, function_str);
+    store_assert_message(message);


Avoid allocator re-entry before aborting asserts

When the intercepted assertion fires from allocator-adjacent code, such as a libc/malloc assertion after heap corruption or while the asserting thread holds an allocator lock, these calls allocate a Rust String/Box before tail-calling the real __assert_fail. That can re-enter or block on the allocator before libc gets to abort, so the process can hang and emit no crash report; capture raw pointers or a fixed-size buffer here and defer formatting until the forked collector runs.

AGENTS.md reference: AGENTS.md:L70-L75

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-07-30T21:12:55Z

+        libdd_got_hook::hook_symbol(
+            c"__assert_fail",
+            hook_assert_fail as *const () as usize,
+            &mut orig_addr,


Keep hooked code valid after unloading the FFI library

In embedders that load libdatadog as the supported .so/FFI library and later dlclose it during extension unload or reload, this permanent GOT patch leaves other modules' __assert_fail slots pointing at hook_assert_fail inside the unloaded image. A subsequent C assert() in any patched module will jump to unmapped/stale code instead of libc, so the hook needs an unpatch/disable-on-unload strategy or the library must be made non-unloadable before patching external GOTs.

AGENTS.md reference: AGENTS.md:L70-L74

Useful? React with 👍 / 👎.

github-actions Bot added the crashtracker label Jul 23, 2026

gyuheon0h changed the title ~~Use GOT patching to retrieve c assert message~~ feat(crashtracking): retrieve c assert message Jul 23, 2026

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from f3e6979 to 6e7f47d Compare July 23, 2026 16:42

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 2 times, most recently from 13ad896 to 28b571f Compare July 23, 2026 17:13

gyuheon0h changed the title ~~feat(crashtracking): retrieve c assert message~~ feat(crashtracking): retrieve c assert message when __assert_fail is dynamically loaded Jul 23, 2026

gyuheon0h changed the title ~~feat(crashtracking): retrieve c assert message when __assert_fail is dynamically loaded~~ feat(crashtracking): retrieve c assert message for linux when __assert_fail is dynamically loaded Jul 23, 2026

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 2 times, most recently from 6b2f473 to 7568fed Compare July 23, 2026 18:28

gyuheon0h marked this pull request as ready for review July 24, 2026 20:45

gyuheon0h requested a review from a team as a code owner July 24, 2026 20:45

chatgpt-codex-connector Bot reviewed Jul 24, 2026

View reviewed changes

Comment thread libdd-crashtracker/src/collector/got_hook.rs Outdated

Comment thread libdd-crashtracker/src/collector/api.rs Outdated

Comment thread libdd-crashtracker/src/collector/got_hook.rs Outdated

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 2 times, most recently from 217836f to b3f0cf7 Compare July 27, 2026 15:13

gyuheon0h marked this pull request as draft July 27, 2026 15:52

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from b8a35c0 to 0af85cb Compare July 27, 2026 15:54

gyuheon0h changed the base branch from main to graphite-base/2268 July 27, 2026 19:13

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from 0af85cb to 4b6482a Compare July 27, 2026 19:14

gyuheon0h changed the base branch from graphite-base/2268 to gyuheon0h/extract-got-hook-crate July 27, 2026 19:14

gyuheon0h mentioned this pull request Jul 27, 2026

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

Open

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 3 times, most recently from c55499a to 2dd85ed Compare July 27, 2026 19:36

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 822405c to 6ab7768 Compare July 27, 2026 20:01

gyuheon0h changed the base branch from graphite-base/2268 to gyuheon0h/got-hook-utils July 29, 2026 16:57

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch from 5f00ce2 to 4618f83 Compare July 29, 2026 18:27

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from fa32bcd to 24789f0 Compare July 29, 2026 18:27

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch from 4618f83 to 8713e2e Compare July 29, 2026 18:28

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 2 times, most recently from 0624b47 to a72626c Compare July 29, 2026 19:01

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch from 8713e2e to 0f700c2 Compare July 29, 2026 19:01

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from a72626c to fe9884f Compare July 29, 2026 19:22

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch from 0f700c2 to 934d93c Compare July 29, 2026 19:22

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 2 times, most recently from b5959b0 to 48971da Compare July 30, 2026 16:39

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch 2 times, most recently from 5e08f80 to e2110f9 Compare July 30, 2026 17:38

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from 48971da to 4156403 Compare July 30, 2026 17:38

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch from e2110f9 to cad573a Compare July 30, 2026 17:50

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 2 times, most recently from d24e571 to 6dbad5d Compare July 30, 2026 18:36

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch from cad573a to 6264ccb Compare July 30, 2026 18:36

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from 6dbad5d to a26fde9 Compare July 30, 2026 18:55

gyuheon0h force-pushed the gyuheon0h/got-hook-utils branch from 6264ccb to d224c5d Compare July 30, 2026 18:58

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from a26fde9 to 0054745 Compare July 30, 2026 18:58

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from 0054745 to 34cd4ce Compare July 30, 2026 21:01

gyuheon0h marked this pull request as ready for review July 30, 2026 21:01

gyuheon0h requested review from a team as code owners July 30, 2026 21:01

chatgpt-codex-connector Bot reviewed Jul 30, 2026

View reviewed changes

gyuheon0h marked this pull request as draft July 30, 2026 21:13

		let message = format_assert_message(assertion_str, file_str, line, function_str);
		store_assert_message(message);

Uh oh!

Conversation

gyuheon0h commented Jul 23, 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 Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pr-commenter Bot commented Jul 23, 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:alloc_free/sampled_system_fast_path/4096

scenario:datadog_sample_span/multiple_rules_last_match/wall_time

scenario:ddsketch_encode/into_pb/clustered_near_zero

scenario:ddsketch_encode/into_pb/collapsing

scenario:ddsketch_encode/into_pb/large_values

scenario:ddsketch_encode/into_pb/mixed

scenario:glob_matcher/unicode_pattern_ascii_subject/wall_time

scenario:glob_matcher/unicode_pattern_wildcard_match/wall_time

scenario:trace_buffer/4_senders/no_delay

Candidate

Baseline

Uh oh!

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

Uh oh!

⚠️ Warnings

ℹ️ Info

Uh oh!

dd-octo-sts Bot commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yannham commented Jul 27, 2026

Uh oh!

gyuheon0h commented Jul 27, 2026

Uh oh!

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

Uh oh!

📚 Documentation Check Results

📦 bin_tests - 1704 warning(s)

📦 libdd-crashtracker - 1111 warning(s)

📦 tools - 173 warning(s)

Uh oh!

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

Uh oh!

🔒 Cargo Deny Results

📦 bin_tests - 4 error(s)

📦 libdd-crashtracker - 2 error(s)

📦 tools - 3 error(s)

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

gyuheon0h commented Jul 23, 2026 •

edited

Loading

gyuheon0h commented Jul 23, 2026 •

edited

Loading

pr-commenter Bot commented Jul 23, 2026 •

edited

Loading

datadog-datadog-prod-us1-2 Bot commented Jul 23, 2026 •

edited by datadog-prod-us1-4 Bot

Loading

dd-octo-sts Bot commented Jul 23, 2026 •

edited

Loading

github-actions Bot commented Jul 29, 2026 •

edited

Loading

📦 `bin_tests` - 1704 warning(s)

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

📦 `tools` - 173 warning(s)

github-actions Bot commented Jul 29, 2026 •

edited

Loading

📦 `bin_tests` - 4 error(s)

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

📦 `tools` - 3 error(s)