You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
README §8 phase 3 justifies ptrace → eBPF as "big overhead win before real workloads." That undersells it. The architectural reason for eBPF is that it moves observation out of the process's blast radius and out of its namespace: rr's dependence on userspace ptrace + HW counters is precisely why it cannot record inside cloud/container environments. eBPF gives a kernel-side vantage point that ptrace structurally cannot.
None of #14/#15/#16 mention containers. Recording a process you did not fork, inside a pid namespace you are not in, is a different problem from tracing a child you spawned.
Scope
Attach to a running PID, not just launch-and-trace. Record from an arbitrary start point (no fork checkpoint available → take an initial CRIU/soft-dirty snapshot on attach).
PID namespace translation. eBPF sees host pids/tgids; DWARF, /proc, and the user see container-namespace pids. Translate at the collector boundary and store both.
cgroup-scoped filtering so a recording captures one container's tasks and not the host's.
Mount-namespace-aware symbol resolution: the target's /lib, its build-id, its debuginfo, are inside its rootfs. Resolve modules through /proc/<pid>/root, key by build-id.
Privilege model, stated honestly. What works with CAP_BPF + CAP_PERFMON vs requiring root; what is impossible on managed Kubernetes with locked-down seccomp; what degrades to the ptrace fallback (feat: ptrace fallback for non-BTF kernels #16). Document the matrix — don't discover it in the field.
Done when
mirrorscope record --pid <pid-in-container> from the host produces a replayable recording with correctly-symbolized frames, and the privilege/degradation matrix is documented.
Ref: README §3.1, §8 phase 3. Gap: "recording in cloud/container/production environments is broken."
Gap
README §8 phase 3 justifies ptrace → eBPF as "big overhead win before real workloads." That undersells it. The architectural reason for eBPF is that it moves observation out of the process's blast radius and out of its namespace:
rr's dependence on userspace ptrace + HW counters is precisely why it cannot record inside cloud/container environments. eBPF gives a kernel-side vantage point that ptrace structurally cannot.None of #14/#15/#16 mention containers. Recording a process you did not fork, inside a pid namespace you are not in, is a different problem from tracing a child you spawned.
Scope
/proc, and the user see container-namespace pids. Translate at the collector boundary and store both./lib, its build-id, its debuginfo, are inside its rootfs. Resolve modules through/proc/<pid>/root, key by build-id.CAP_BPF+CAP_PERFMONvs requiring root; what is impossible on managed Kubernetes with locked-down seccomp; what degrades to the ptrace fallback (feat: ptrace fallback for non-BTF kernels #16). Document the matrix — don't discover it in the field.Done when
mirrorscope record --pid <pid-in-container>from the host produces a replayable recording with correctly-symbolized frames, and the privilege/degradation matrix is documented.Ref: README §3.1, §8 phase 3. Gap: "recording in cloud/container/production environments is broken."