Skip to content

Linux: decouple deleted-library maps scan cadence#2011

Open
Komzpa wants to merge 1 commit into
htop-dev:mainfrom
Komzpa:fixer-deleted-lib-map-scan
Open

Linux: decouple deleted-library maps scan cadence#2011
Komzpa wants to merge 1 commit into
htop-dev:mainfrom
Komzpa:fixer-deleted-lib-map-scan

Conversation

@Komzpa

@Komzpa Komzpa commented May 26, 2026

Copy link
Copy Markdown
Contributor

Summary

When deleted executable/library highlighting is enabled, Linux process refresh currently shares the same last_mlrs_calctime throttle for both the M_LRS column and deleted-library detection.

That couples two different behaviours:

  • M_LRS can need frequent maps scans while the column is visible.
  • Deleted-library highlighting only needs occasional rechecks, and should not be cleared by an unrelated M_LRS-only scan.

This adds a separate last_deleted_lib_calctime, clears usesDeletedLib only when the deleted-library check actually runs, and keeps a periodic deleted-library recheck so the marker can clear after a process unloads the deleted mapping.

Validation

  • ./autogen.sh && ./configure && make -j8
  • make check
  • git diff --check origin/main...HEAD
  • Manual runtime repro with a process that dlopen()s a temporary shared object and unlinks it while it remains mapped.
  • Noninteractive htop smoke with a config showing EXE and M_LRS columns confirmed the process row is rendered and M_LRS is populated.
  • TTY strace -yy comparison with only EXE/Command visible and deleted-library highlighting enabled:
    • patched branch, ~14.5s: 798 total maps opens, 2 for the target process
    • current main, ~15.4s: 3450 total maps opens, 9 for the target process
  • A second repro process dlclose()d the deleted library after startup; the patched branch rechecked the target maps 4 times during a ~35.7s run after the mapping disappeared.

@coderabbitai

coderabbitai Bot commented May 26, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: dc7bf469-b412-4adc-9dd3-827c52e7b399

📥 Commits

Reviewing files that changed from the base of the PR and between d384ae4 and 166a457.

📒 Files selected for processing (2)
  • linux/LinuxProcess.h
  • linux/LinuxProcessTable.c

📝 Walkthrough

Summary

This PR decouples the throttle for /proc/*/maps scanning into two independent schedules: one for M_LRS recalculation and one for deleted-library detection.

Changes

  • linux/LinuxProcess.h

    • Added unsigned long long last_deleted_lib_calctime to track deleted-library check timing.
  • linux/LinuxProcessTable.c

    • LinuxProcessTable_readMaps now only clears proc->usesDeletedLib when the deleted-library check runs; it accepts explicit calcSize and checkDeletedLib parameters.
    • Recursion logic split into two independent triggers:
      • checkLrs (M_LRS) uses last_mlrs_calctime and existing randomized spacing.
      • checkDeletedLib (deleted-library highlighting) uses last_deleted_lib_calctime with its own randomized cadence (10s base).
    • maps is read only if at least one check fires; state is cleaned appropriately when checks are inactive.

Implementation quality

Clean, minimal change that separates concerns with consistent patterns. Timestamp split and conditional invocation avoid extra scans without adding complexity. Edge cases (clearing usesDeletedLib only when relevant, periodic rechecks after unload) are handled. Code flow is straightforward and easy to review.

Validation

Build and make check passed. Manual and strace-based runtime tests show substantially fewer /proc/*/maps opens and correct clearing of deleted-library markers after unload.

Commit structure

Single focused commit with clear scope and message; changes are cohesive and in-scope.

Walkthrough

The PR adds a new timestamp field, last_deleted_lib_calctime, to LinuxProcess. The recursion logic now computes two independent booleans—checkLrs and checkDeletedLib—using separate last-calculation timestamps and randomized recheck intervals. LinuxProcessTable_readMaps is called only when at least one check triggers; each check’s timestamp is updated independently. When neither check triggers, proc->usesDeletedLib and lp->m_lrs are cleared only under the appropriate conditional paths.

Poem

Two timers tick for files and LRS,
Each with its own small, measured pulse.
One finds deleted libs that slip away,
The other keeps LRS counts in place—
Now they wake and work on separate time.


Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 1


ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: a6f6241f-5f9d-47ab-91ae-5e92467671bd

📥 Commits

Reviewing files that changed from the base of the PR and between ac2cdee and d384ae4.

📒 Files selected for processing (2)
  • linux/LinuxProcess.h
  • linux/LinuxProcessTable.c

Comment thread linux/LinuxProcessTable.c
@Komzpa Komzpa force-pushed the fixer-deleted-lib-map-scan branch from d384ae4 to 166a457 Compare May 27, 2026 00:16
@BenBE BenBE added the enhancement Extension or improvement to existing feature label May 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Extension or improvement to existing feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants