Skip to content

Clamp idle timeouts to the int32 millisecond range - #11353

Closed
rand0mdud3 wants to merge 1 commit into
omacom:quattrofrom
rand0mdud3:fix-idle-timer-overflow
Closed

rand0mdud3 wants to merge 1 commit into
omacom:quattrofrom
rand0mdud3:fix-idle-timer-overflow

Conversation

@rand0mdud3

Copy link
Copy Markdown

Fixes #11329.

secondsFromConfig had no upper bound, so a large idle.lock (e.g. 999999999, used as effectively-never) overflowed QML Timer.interval (32-bit signed ms) into a negative number. Qt clamps that to 1ms and the timer free-runs, spamming QBasicTimer warnings at ~1kHz (~1GB/session) and filling /run/user tmpfs.

  • IdleModel.secondsFromConfig now clamps to 2147483s (floor(2^31-1 / 1000), ~24.8 days): the largest value that survives the seconds-to-ms conversion. This is the single choke point for both the lock and screensaver timers. A 24-day timeout preserves the effectively-never intent with zero behavior change for sane values.
  • Tests: 3 new assertions in idle-test.sh (clamp, boundary keep, boundary+1 clamp).

Verified for real on MacBookPro11,5, not just mocks. Repro: screensaver 10 + lock 999999999, restart shell, stay idle 2 min: fresh log grew 0 to 9.8MB with 82,885 QBasicTimer warnings and climbing. Then the same one-line clamp applied to the installed copy, same repro: full window, 0 warnings, ~6KB log, no spurious lock. Installed file restored byte-identical afterwards (checksum-verified) and stock config (150/300) put back.

@rand0mdud3
rand0mdud3 force-pushed the fix-idle-timer-overflow branch from f914697 to cdb4b32 Compare September 11, 2026 18:45

@johnpippett johnpippett 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.

The timeout correction gave the required results in the automatic checks below. The checks found no regression in these cases.

Head: cdb4b3289ba09316d46c5026e3439617a93ddc08
Base: b5589faaf80c6f87c07d4560fca37c4a81722f28

Each revision had these checks:

  • test/shell.d/idle-test.sh: 9 assertions on the base and 12 on the head, all with the required results.
  • test/shell.d/system-lock-test.sh: the assertion gave the required result with command stubs.
  • The IdleModel.js file at each revision: 32 specified cases and 10,000 generated finite values, all with the required results.
  • QML integer properties and Timer.interval: 33 configurations per revision, including both deadline orders and values at the integer limit.

The QML fixture imported the JavaScript module from each source revision. Its scalar properties and interval expressions came directly from Service.qml. Both timers stayed stopped during the checks. The fixture did not load the idle service or create an IdleMonitor.

All head intervals stayed within the signed 32-bit millisecond range. Thirteen ordinary, incorrect-input, and type-conversion configurations gave the same results on both revisions.

Environment: Linux x86_64, Qt 6.11.2, Node 26.7.0, and bubblewrap 0.11.2. Each test process had an empty home directory and no network or desktop access.

The test scope did not include live idle behavior, timer operation, log growth, or lock-screen behavior. It did not include graphical acceptance tests.

Codex agents did these tests and prepared this review.

@bjarneo

bjarneo commented Sep 21, 2026

Copy link
Copy Markdown
Member

Automated duplication check: this pull request looks similar to #7578, which covers the same idle timeout int32 clamp. I keep that one open and close this one to consolidate review.

If you feel this is the wrong decision, please open the PR again with a note on the difference.

@bjarneo bjarneo closed this Sep 21, 2026
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.

idle.lock: large values overflow the lock Timer's 32-bit interval, causing an infinite 1kHz warning loop and ~1GB/session log growth

3 participants