fix(gui): report phys_footprint for status-bar memory on macOS (#3197). Principle III.#3214
fix(gui): report phys_footprint for status-bar memory on macOS (#3197). Principle III.#3214aethersdr-agent[bot] wants to merge 1 commit into
Conversation
…. Principle III. Replace the macOS getrusage(ru_maxrss) reading in the status-bar memory telemetry with task_info(TASK_VM_INFO) → phys_footprint, which is the same metric Activity Monitor displays in its "Memory" column and that the kernel's resource-pressure / jetsam system actually consults. The previous reading was ~3.8× lower than Activity Monitor on Apple Silicon (859 MB vs 3.19 GB in the reporter's session) because ru_maxrss is a monotonic high-water mark of anonymous RSS only and excludes compressed pages, IOKit/Metal mappings, and purgeable memory — all of which dominate a Qt+QRhi process's footprint on macOS. While in the same block, switch the Linux arm to read VmRSS from /proc/self/status so it reports current resident set size rather than the ru_maxrss high-water mark, matching top/htop and unifying behavior across platforms (Windows GetProcessMemoryInfo→WorkingSetSize is already current). Update the tooltip on macOS to reflect that the new value is the physical footprint rather than RSS. Cites Principle III (User-Facing Names Match The Visible UI Labels) in the extended sense the principle was written for: the on-screen number a user can compare against — Activity Monitor's "Memory" column — is what the status-bar readout must agree with. A 3.8× discrepancy is the same support-friction failure mode as asking a user to look for a button by its internal class name. Per the issue's separately-noted follow-up: whether ~3 GB resident on an idle single-slice session is itself excessive (waterfall tile retention, Metal/QRhi overhead, FFT history, leaked textures, etc.) is out of scope for this display fix and is a good case for the per-thread memory trending in the forthcoming System Info diagnostics dialog (#2554). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
Thanks @VU3ESV — this looks good. Clean, well-scoped fix to a single file, with the right rationale baked into comments.
A few things I checked:
- macOS path —
task_vm_info_data_t vmInfo{}zero-init,mach_task_self(),TASK_VM_INFO_COUNTand theKERN_SUCCESScheck are all correct.phys_footprintis the value Activity Monitor renders, so by construction the two readouts agree. - Linux
/proc/self/statusparsing — robust enough:indexOf("VmRSS:") >= 0guards missing field,toULongLong(&ok)guards malformed value, and ifindexOf('\n', idx)returns -1 (VmRSS is the last line),QByteArray::mid(idx, -1-idx)falls back to "from pos to end of array" per Qt docs, so the parse still succeeds.QFileis RAII so no leak. - Includes correctly gated under
Q_OS_MAC. - Tooltip updated to reflect the new metric on macOS; Linux/Windows tooltip is also tightened to "RSS" — accurate.
Failure modes on all three platforms leave the previous label text in place, which is the right degradation behavior.
No issues from me. 73
🤖 aethersdr-agent · cost: $5.3286 · model: claude-opus-4-7
|
Closing as duplicate — @VU3ESV's #3207 shipped the same fix ~12 minutes before this opened. Thanks for the independent triage, agent; your inline reasoning on why |
Pull request was closed
Summary
Fixes #3197
What was changed
fix(gui): report phys_footprint for status-bar memory on macOS (#3197). Principle III.
Files modified
src/gui/MainWindow.cppGenerated by AetherClaude (automated agent for AetherSDR)
🤖 aethersdr-agent · cost: $7.5967 · model: claude-opus-4-7