libdatadog update to 36b879aa

[dd-octo-sts]

Summary

Automated update of the libdatadog submodule to the latest HEAD.

	SHA
Previous	$LIBDATADOG_PINNED_SHA
New	36b879aa6ce0e6bd557094e425c2eab9d472119d

Full CI result: ❌ 571 job(s) failed
CI pipeline: https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/pipelines/123435980

---

libdatadog Integration Report

libdatadog SHA: 36b879aa6ce0e6bd557094e425c2eab9d472119d
Analysis date: 2026-07-08

Overall status

❌ Blocking issues remain

A single removed FFI export (ddog_sidecar_get_crashtracker_unix_socket_path) breaks
crashtracker initialization in the tracer extension, and there is no C-FFI replacement
to adapt to. All 571 failing jobs cascade from this one symbol. This must be resolved in
libdatadog (by re-exposing the necessary FFI) before the update can land.

Build & test summary

The Rust/C build of ddtrace.so itself succeeds — this is a link/runtime failure, not a
compile failure. The generated header components-rs/sidecar.h still declares
ddog_sidecar_get_crashtracker_unix_socket_path() and ext/signals.c calls it, but the new
libdatadog no longer defines that symbol. As soon as any PHP process loads ddtrace.so and
triggers crashtracker init, dynamic symbol resolution fails:

php: symbol lookup error: .../ddtrace.so: undefined symbol: ddog_sidecar_get_crashtracker_unix_socket_path

Because crashtracker init runs whenever DD_INSTRUMENTATION_TELEMETRY_ENABLED=1 and
DD_CRASHTRACKING_ENABLED are on (see datadog_signals_first_rinit →
dd_init_crashtracker in ext/signals.c), essentially every extension-dependent job fails.

Failure distribution (from ci_summary.txt / all_failures.json), all with the same root cause:

• tracer: ASAN test_c, PHP Language Tests, all test_web_*, all test_integrations_*,
  test_distributed_tracing, test_opentracing_10, Internal api randomized tests,
  windows test_c, pecl tests, etc.
• shared: Extension Tea Tests (all versions/variants).
• appsec: test appsec extension (only the one test client_init_sidecar.phpt fails — it is
  the only appsec-extension test that sets DD_INSTRUMENTATION_TELEMETRY_ENABLED=1 and thus
  reaches crashtracker init; the other 343 pass because lazy symbol binding never resolves the
  missing symbol), appsec integration tests, helper-rust integration coverage,
  appsec code coverage.
• package: verify debian/alpine/centos/.tar.gz, Loader test, System Tests.

Only two distinct error signatures appear across every failure trace:
undefined symbol: ddog_sidecar_get_crashtracker_unix_socket_path (the direct cause) and the
client_init_sidecar.phpt failure (the same cause, surfaced as a failing .phpt).

Non-trivial changes made

No code changes were made.

The call site (ext/signals.c:253, dd_init_crashtracker) cannot be adapted, because the new
libdatadog does not expose an FFI path to obtain the sidecar IPC socket or to wire the
crashtracker to it (details below). The only possible "adaptation" available on our side would be
to delete/disable crashtracker initialization, which would silently drop crash-tracking
functionality — a prohibited workaround, not a fix. The code is intentionally left broken pending
a libdatadog FFI fix.

Identified libdatadog issues

refactor(sidecar)!: Avoid a dedicated socket for crashtracker (#2179, commit e91210ef9) removed a public FFI without a Unix replacement

Symptom: ddtrace.so fails at runtime with
undefined symbol: ddog_sidecar_get_crashtracker_unix_socket_path.

What changed: PR #2179 reworked the crashtracker so the crash-time collector connects to the
sidecar's single IPC socket and "upgrades" that connection into a crashtracker receiver, instead
of using a second dedicated socket. As part of this it deleted the FFI export
ddog_sidecar_get_crashtracker_unix_socket_path from datadog-sidecar-ffi/src/lib.rs
(the commit diff for that file is 16 lines, all deletions — no replacement function was added).

Why this blocks us and cannot be worked around in dd-trace-php: ext/signals.c needs
(a) the socket path to point the crashtracker at, and (b) on Linux, a connector that sends the
enter_crashtracker_receiver handshake as its first message so the sidecar's serve loop switches
that connection into receiver mode. The new design implements both, but only as internal Rust
APIs that are not reachable over the C FFI:

• datadog_sidecar::crashtracker::crashtracker_ipc_socket_path() — returns the sidecar IPC socket
  path, but is a plain pub fn, not #[no_mangle]. No FFI wrapper exists.
• datadog_sidecar::crashtracker::connect_to_sidecar_receiver() /
  crashtracker_receiver_request_bytes() — implement the required handshake, again pub fn only,
  no FFI wrapper.
• libdd-crashtracker gained a configurable unix_socket_connector (fn(&str) -> RawFd), but the
  C-FFI config struct ddog_crasht_Config
  (libdd-crashtracker-ffi/src/collector/datatypes.rs) exposes no field for it, and its
  TryFrom<Config> for CrashtrackerConfiguration never calls unix_socket_connector(...) — so an
  FFI caller is always stuck with default_unix_socket_connector, a plain connect() that omits
  the enter_crashtracker_receiver handshake.
• The only crashtracking-setup FFI in datadog-sidecar-ffi is ddog_setup_crashtracking, which is
  gated #[cfg(target_os = "windows")] — there is no Unix equivalent.

Net result: on Unix there is no supported FFI to (1) obtain the sidecar IPC socket path or (2)
install the sidecar-aware connector. A C consumer therefore cannot reproduce the new flow.

Suggested libdatadog fix (any one of):

• Re-add a Unix FFI that returns the sidecar IPC socket path (e.g.
  ddog_sidecar_get_crashtracker_unix_socket_path backed by crashtracker_ipc_socket_path()),
  and add an FFI-settable connector (or a dedicated
  ddog_crasht_config_set_sidecar_connector) plus a way to prime
  crashtracker_receiver_request_bytes; or
• Provide a single high-level Unix FFI mirroring the Windows-only ddog_setup_crashtracking that
  performs the full sidecar-IPC crashtracker setup internally, so consumers do not need the socket
  path or connector at all.

Until libdatadog re-exposes one of these, ext/signals.c cannot be updated to a working state.

Flaky / ignored failures

None. Every failing job across all sub-pipelines traces back to the single missing symbol above;
no timing/race/flaky or unrelated-infrastructure failures were identified.

---

/cc @bwoebi

[datadog-prod-us1-3]

 

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 1621 Pipeline jobs failed

DataDog/apm-reliability/dd-trace-php | appsec integration tests: [test8.5-release]     

🧪 20 Tests failed

[1] file_get_contents, 19 from com.datadog.appsec.php.integration.Apache2FpmTests  

Assertion failed: 

assert re.statusCode() == 200
       |  |            |
       |  503          false
       (GET http://docker:32770/ssrf.php?function=file_get_contents&domain=169.254.169.254) 503

Assertion failed: 

assert re.statusCode() == 200
...

[1] file_put_contents, /tmp/dummy, 9 from com.datadog.appsec.php.integration.Apache2FpmTests  

Assertion failed: 

assert re.statusCode() == 200
       |  |            |
       |  503          false
       (GET http://docker:32770/filesystem.php?function=file_put_contents&path=/tmp/dummy) 503

Assertion failed: 

assert re.statusCode() == 200
...

View all failed tests

DataDog/apm-reliability/dd-trace-php | ASAN test_c with multiple observers: [8.1]     

DataDog/apm-reliability/dd-trace-php | ASAN test_c with multiple observers: [8.4]     

View all 1621 failed jobs.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

🔄 Datadog auto-retried 126 jobs - 13 passed on retry

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 27525c1 | Docs | Datadog PR Page | Give us feedback!}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 91b5f2bade

ℹ️ 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]

Regenerate Cargo.lock for the new libdatadog versions

This bump points at a libdatadog revision that changes path package versions (libdd-common 4.2.0→5.0.0 and libdd-remote-config 0.1.0→1.0.0), but the parent Cargo.lock is unchanged and still records the old versions. I checked cargo build --help; --locked asserts the lockfile remains unchanged, so locked/reproducible builds from this commit will fail before compilation because Cargo must rewrite the lockfile for those path dependencies. Please regenerate and commit Cargo.lock with this submodule revision.

Useful? React with 👍 / 👎.

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-07-07 06:03:36

Comparing candidate commit ef020cf in PR branch bot/libdatadog-latest with baseline commit 0c09f3c in branch master.

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

Explanation

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

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

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

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

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

More details about the CI and significant changes

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

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

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

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

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

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

scenario:MessagePackSerializationBench/benchMessagePackSerialization

• 🟥 execution_time [+2.888µs; +3.652µs] or [+2.752%; +3.481%]

scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache

• 🟥 execution_time [+4.593µs; +6.247µs] or [+4.337%; +5.899%]