[SLOP(claude-opus-4-8-medium)] chore: add profiling cargo profile for heaptrack leak investigation

[MasterPtato]

No description provided.

[MasterPtato]

Stack for rivet-dev/rivet

• [SLOP(claude-opus-4-8-medium)] fix(rivetkit-napi): reap completed tasks from event-loop JoinSet #5315 vtlztrkn · 2026-06-22 22:42:02
• [SLOP(claude-opus-4-8-medium)] chore: add profiling cargo profile for heaptrack leak investigation #5314 xsoysnqs · 2026-06-22 22:42:01 👈
• [SLOP(claude-opus-4-8)] fix(kitchen-sink): serve built frontend from server #5306 rymmurrk · 2026-06-19 01:04:14
• main

Get stack: forklift get 5314
Push local edits: forklift submit
Merge when ready: forklift merge 5314

[claude]

This PR adds a [profile.profiling] Cargo profile aimed at heaptrack-based leak investigation: it inherits from release, adds line-table debug info, switches to thin LTO, raises codegen-units to 16, and explicitly sets strip = false. Two actionable issues and one minor redundancy survived verification.

---

Cargo.toml:663 — debug = 1 omits inline-frame DWARF, making heaptrack attribution inaccurate for inlined allocation paths

Cargo debug = 1 maps to -Cdebuginfo=line-tables-only: it emits .debug_line sections (file/line for each PC) but does not emit DW_TAG_inlined_subroutine entries in .debug_info. heaptrack resolves backtraces through addr2line/libdw, which can only expand inlined frames when those DWARF inline records exist. At opt-level = 3 (inherited from release), LLVM inlines aggressively, so many allocation call sites are collapsed into the nearest surviving non-inlined frame. With debug = 1, heaptrack shows that surviving frame — not the actual source line that allocated — making it harder to attribute leaks to the correct user code. The fix is debug = 2 (full DWARF). The binary will be larger but inline frame chains become visible.

-debug = 1
+debug = 2

---

Cargo.toml:660 — Comment "keep frames un-inlined" overstates what codegen-units = 16 does

The comment reads: "Uses thin LTO and more codegen units to keep frames un-inlined and builds fast." codegen-units controls how many parallel compilation units LLVM sees, which only limits cross-unit inlining (the part LTO normally enables). Within each CGU, LLVM's inliner runs at full -O3 strength regardless of unit count. Since most hot allocation paths live within a single crate/CGU, within-unit inlining is the dominant source of collapsed frames. lto = "thin" does reduce cross-unit inlining vs lto = "fat", but that effect belongs to the LTO setting, not the CGU count. The "builds fast" part is accurate. A more precise comment:

# Uses thin LTO (faster builds, less cross-unit inlining than fat LTO) and more
# codegen units for faster incremental compilation.

---

Cargo.toml:666 — strip = false is redundant

Cargo's default for strip is false; the inherited [profile.release] does not set it. strip = false here is a no-op. The accompanying comment frames it as a meaningful choice ("no symbol stripping so heaptrack can resolve..."), which is accurate as intent but the explicit setting adds no behavior. It can be dropped to avoid implying the default would otherwise strip.

[railway-app]

🚅 Deployed to the rivet-pr-5314 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	Jun 22, 2026 at 10:54 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Jun 22, 2026 at 10:53 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Jun 22, 2026 at 10:52 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Jun 22, 2026 at 10:51 pm
ladle	✅ Success (View Logs)	Web	Jun 22, 2026 at 10:43 pm
mcp-hub	✅ Success (View Logs)	Web	Jun 22, 2026 at 10:42 pm