Skip to content

fix(gui): report phys_footprint for status-bar memory on macOS (#3197). Principle III.#3214

Closed
aethersdr-agent[bot] wants to merge 1 commit into
mainfrom
aetherclaude/issue-3197
Closed

fix(gui): report phys_footprint for status-bar memory on macOS (#3197). Principle III.#3214
aethersdr-agent[bot] wants to merge 1 commit into
mainfrom
aetherclaude/issue-3197

Conversation

@aethersdr-agent
Copy link
Copy Markdown
Contributor

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.cpp
 src/gui/MainWindow.cpp | 59 ++++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 48 insertions(+), 11 deletions(-)

Generated by AetherClaude (automated agent for AetherSDR)


🤖 aethersdr-agent · cost: $7.5967 · model: claude-opus-4-7

…. 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>
Copy link
Copy Markdown
Contributor Author

@aethersdr-agent aethersdr-agent Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 pathtask_vm_info_data_t vmInfo{} zero-init, mach_task_self(), TASK_VM_INFO_COUNT and the KERN_SUCCESS check are all correct. phys_footprint is the value Activity Monitor renders, so by construction the two readouts agree.
  • Linux /proc/self/status parsing — robust enough: indexOf("VmRSS:") >= 0 guards missing field, toULongLong(&ok) guards malformed value, and if indexOf('\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. QFile is 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

@ten9876
Copy link
Copy Markdown
Collaborator

ten9876 commented May 27, 2026

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 phys_footprint (kernel resource-pressure system uses it, IOKit/Metal mappings included) was nice to see. The merged version uses a slightly cleaner hoisted-variable pattern but the behaviour is identical.

@ten9876 ten9876 closed this May 27, 2026
auto-merge was automatically disabled May 27, 2026 14:33

Pull request was closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

macOS: in-app status-bar memory readout (~859 MB) drastically underreports OS-reported footprint (~3.19 GB) for AetherSDR v26.5.3

1 participant