fix(valgrind): use %p in log file path to avoid multi-process overwrite

[not-matthias]

What?

With --trace-children=yes, every (forked) process wrote to the same valgrind.log file, so the last writer won and earlier processes' logs were lost.

This uses the %p (PID) placeholder in --log-file so each process gets its own valgrind.<pid>.log, matching the existing %p.out (callgrind) and %p.tgtrace (tracegrind) out-file patterns.

Also drops the failure-path read of the now-nonexistent hardcoded valgrind.log.

Closes COD-2747

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 7 untouched benchmarks

---

_{Comparing cod-2747-multi-process-valgrind-logs-can-overwrite-log-file (ce58003) with main (82af5a5)}

[greptile-apps]

Greptile Summary

This PR fixes a log-overwrite race condition when valgrind is run with --trace-children=yes: previously all forked processes wrote to a shared valgrind.log and only the last writer's output survived. The fix uses the valgrind %p PID placeholder (consistent with the existing %p.out / %p.tgtrace output-file patterns) so each process gets its own log, and updates the failure-path handler to glob and emit all matching valgrind.<pid>.log files.

• Changes log_path from the fixed string valgrind.log to valgrind.%p.log so every forked process under --trace-children=yes writes to a distinct file, eliminating last-writer-wins data loss.
• Replaces the single-file read on failure with a directory scan that surfaces every valgrind.*.log file via debug!, restoring diagnostic visibility that was lost by dropping the hardcoded path.

Confidence Score: 5/5

Safe to merge — the change is minimal and well-scoped, replacing a single hardcoded log path with a %p-keyed one and adding a matching directory scan on the failure path.

The fix directly mirrors the existing %p.out / %p.tgtrace patterns already used for callgrind and tracegrind output files, so the approach is proven and consistent. The failure-path glob correctly constrains matches to valgrind.*.log and silently skips unreadable entries, which is appropriate for a diagnostic-only code path. No logic paths are broken or removed.

No files require special attention.

Important Files Changed

Filename	Overview
src/executor/valgrind/measure.rs	Adds %p PID placeholder to the valgrind log path and updates the failure-path handler to scan all matching valgrind..log files; logic is correct and consistent with the existing out-file patterns.

Sequence Diagram

sequenceDiagram
    participant C as Caller (measure)
    participant V as valgrind (parent, PID=100)
    participant C1 as child process (PID=101)
    participant C2 as child process (PID=102)
    participant FS as profile_folder

    C->>V: "setarch valgrind --log-file=folder/valgrind.%p.log --trace-children=yes"
    V->>FS: writes valgrind.100.log
    V->>C1: fork + exec
    C1->>FS: writes valgrind.101.log
    V->>C2: fork + exec
    C2->>FS: writes valgrind.102.log

    alt valgrind exits non-zero
        C->>FS: read_dir(profile_folder)
        FS-->>C: [valgrind.100.log, valgrind.101.log, valgrind.102.log]
        loop "each valgrind.*.log"
            C->>FS: read_to_string(file)
            FS-->>C: contents
            C->>C: debug!(path + contents)
        end
        C->>C: bail!(failed to execute valgrind)
    end

Loading

_{Reviews (3): Last reviewed commit: "style: cargo fmt" | Re-trigger Greptile}