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

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-27 21:16:39

Comparing candidate commit 6fca2eb in PR branch gyuheon0h/PROF-15482-c-assert-msg with baseline commit 38d3caa in branch gyuheon0h/extract-got-hook-crate.

Found 4 performance improvements and 0 performance regressions! Performance is the same for 173 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:glob_matcher/ascii_wildcard_backtrack_match/wall_time

🟩 execution_time [-2.666ns; -2.649ns] or [-6.639%; -6.596%]

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/wall_time

🟩 execution_time [-2.956ns; -2.929ns] or [-6.719%; -6.657%]

scenario:glob_matcher/ascii_wildcard_question_match/wall_time

🟩 execution_time [-25.085ns; -25.058ns] or [-40.451%; -40.407%]

scenario:glob_matcher/ascii_wildcard_star_match/wall_time

🟩 execution_time [-25.139ns; -25.111ns] or [-40.542%; -40.496%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

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

Tests

⚠️ Warnings

❄️ 1 New flaky test detected

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

thread &#39;collector::assert_interceptor::tests::test_install_assert_hook&#39; panicked at libdd-crashtracker/src/collector/assert_interceptor.rs:190:9

thread &#39;collector::assert_interceptor::tests::test_install_assert_hook&#39; panicked at libdd-crashtracker/src/collector/assert_interceptor.rs:190:9:
should resolve the original __assert_fail
note: run with \`RUST_BACKTRACE=1\` environment variable to display a backtrace

New test introduced in this PR is flaky.

View in Flaky Test Management

ℹ️ Info

No other issues found (see more)

🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 63.27%
• Overall Coverage: 74.75% (+0.04%)

Useful? React with 👍 / 👎

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

🔗 Commit SHA: 6fca2eb | 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.14 MB	87.26 MB	+.14% (+129.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.41 MB	98.52 MB	+.10% (+108.63 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.77 MB	10.78 MB	+.02% (+2.46 KB) 🔍

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	26.00 MB	26.00 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	89.18 KB	89.18 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	187.96 MB	187.94 MB	-0% (-16.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	979.41 MB	979.41 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.47 MB	8.47 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	89.18 KB	89.18 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	25.05 MB	25.05 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	49.85 MB	49.85 MB	0% (0 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.64 MB	22.64 MB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	90.58 KB	90.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	192.64 MB	192.63 MB	-0% (-8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	968.48 MB	968.48 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.54 MB	6.54 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	90.58 KB	90.58 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	26.91 MB	26.91 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	47.44 MB	47.44 MB	0% (0 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	77.73 MB	77.87 MB	+.17% (+141.56 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.91 MB	8.93 MB	+.17% (+16.00 KB) 🔍

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	93.24 MB	93.38 MB	+.14% (+143.18 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.85 MB	10.86 MB	+.12% (+14.06 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-27T19:16:52Z

📚 Documentation Check Results

⚠️ 2815 documentation warning(s) found

📦 `bin_tests` - 1704 warning(s)

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

Updated: 2026-07-27 20:32:43 UTC | Commit: 19cf203 | missing-docs job results

github-actions · 2026-07-27T19:17:38Z

🔒 Cargo Deny Results

⚠️ 6 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

Updated: 2026-07-27 20:33:40 UTC | Commit: 19cf203 | 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.

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

Draft

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

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch 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 force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from 2dd85ed to 854221b Compare July 27, 2026 20:01

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

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from 854221b to 6e261bd Compare July 27, 2026 20:06

gyuheon0h force-pushed the gyuheon0h/PROF-15482-c-assert-msg branch from 6e261bd to 6fca2eb Compare July 27, 2026 20:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(crashtracking): retrieve c assert message for linux when `__assert_fail` is dynamically loaded - #2268

feat(crashtracking): retrieve c assert message for linux when `__assert_fail` is dynamically loaded#2268
gyuheon0h wants to merge 1 commit into
gyuheon0h/extract-got-hook-cratefrom
gyuheon0h/PROF-15482-c-assert-msg

gyuheon0h commented Jul 23, 2026 •

edited

Loading

Uh oh!

gyuheon0h commented Jul 23, 2026 •

edited

Loading

Uh oh!

pr-commenter Bot commented Jul 23, 2026 •

edited

Loading

Explanation

More details about the CI and significant changes

Uh oh!

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

edited by datadog-prod-us1-3 Bot

Loading

Uh oh!

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

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

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 27, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jul 27, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

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:glob_matcher/ascii_wildcard_backtrack_match/wall_time

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/wall_time

scenario:glob_matcher/ascii_wildcard_question_match/wall_time

scenario:glob_matcher/ascii_wildcard_star_match/wall_time

Candidate

Baseline

Uh oh!

datadog-datadog-prod-us1-2 Bot commented Jul 23, 2026 • edited by datadog-prod-us1-3 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 27, 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)

Uh oh!

github-actions Bot commented Jul 27, 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)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

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-3 Bot

Loading

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

edited

Loading

github-actions Bot commented Jul 27, 2026 •

edited

Loading

📦 `bin_tests` - 1704 warning(s)

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

github-actions Bot commented Jul 27, 2026 •

edited

Loading

📦 `bin_tests` - 4 error(s)

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