[not-matthias]

Install libc6-dbg during memory and walltime setup, as the valgrind setup already does.

Ubuntu's libc is stripped and only ships .dynsym, so glibc's static functions (__libc_start_call_main, start_thread, clone3) have no symbol. Their frames are then named after their runtime address, which changes on every run because of ASLR. The same frame never matches across runs, so a differential flamegraph marks everything below it as new or dropped. The runner already warns about the missing debug file after the run, but nothing installed it outside valgrind mode.

The install is best effort and never fails the setup:

• skipped when the libc debug file is already present, probed by file because the setup cache restores files without updating dpkg
• skipped on non-apt systems and on macOS
• skipped with a warning when elevating would need a password prompt (not root, no passwordless sudo)
• a failed install only logs a warning
• walltime installs it only when a profiler is configured

The libc debug file probe and the "missing libc debug symbols" warning move out of the valgrind setup into a shared helper, and the warning no longer says "valgrind". The valgrind setup otherwise behaves as before.

Only libc is covered. Other stripped modules (libstdc++, stripped user binaries) still show up as addresses, so the issue stays open. Resolving symbols through debuginfod would cover those, and the install can then go away (FIXME in both setups).

Verified by recording an allocating C program with codspeed exec --mode memory in an ubuntu:24.04 container that had no libc6-dbg. Setup installed the package, and the parsed profile named __libc_start_call_main, clone3 and start_thread instead of addresses. I did not run the walltime path end to end.

Refs COD-4026

[codspeed]

Merging this PR will degrade performance by 12.57%

2 warnings

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚠️ 8 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

❌ 1 regressed benchmark
✅ 38 untouched benchmarks
⏩ 8 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Walltime	memtrack track tar	8.2 s	9.3 s	-12.57%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing cod-4026-fix-unknown-symbols-in-memory-flamegraphs (aadcdc1) with main (ea54386)}

Footnotes

1. 8 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable new defects were found.

Summary

Adds best-effort libc6-dbg installation to memory and wall-time setup and shares the same helper with Valgrind.

• Profiling setup tries to give libc frames their real names.
• Shared setup caches keep package names from earlier installs.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Memory, wall-time, or Valgrind setup] --> B{Apt-based host?}
  B -- No --> S[Skip]
  B -- Yes --> C{Matching libc debug file exists?}
  C -- Yes --> S
  C -- No --> D{Can elevate without a prompt?}
  D -- No --> W[Warn and continue]
  D -- Yes --> E[Restore cache or install libc6-dbg]
  E --> F{Succeeded?}
  F -- Yes --> G[Continue setup]
  F -- No --> W

Loading

_{Reviews (2) · Last reviewed commit: "fix: install libc debug symbols during e..." · Reviewed by Greptile}

[GuillaumeLagrange]

olgtm